[issue40971] Documentation still mentions 'u' string formatting option
New submission from Gordon P. Hemsley : https://docs.python.org/3/library/stdtypes.html#old-string-formatting still lists the 'u' string formatting option, described as "Obsolete type – it is identical to 'd'." and linking to PEP 237. However, testing indicates that Python 3 does not support a 'u' option and my archaeology suggests that such support was removed in Python 2.4. It seems this has flown under the radar for quite some time. -- assignee: docs@python components: Documentation messages: 371474 nosy: alexandre.vassalotti, benjamin.peterson, berker.peksag, christian.heimes, docs@python, eli.bendersky, ezio.melotti, georg.brandl, gphemsley, martin.panter, ncoghlan, rhettinger priority: normal severity: normal status: open title: Documentation still mentions 'u' string formatting option type: behavior versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36967] Eliminate unnecessary check in _strptime when determining AM/PM
Change by Gordon P. Hemsley : -- components: +Library (Lib) ___ Python tracker <https://bugs.python.org/issue36967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36967] Eliminate unnecessary check in _strptime when determining AM/PM
Change by Gordon P. Hemsley : -- keywords: +patch pull_requests: +13338 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36967] Eliminate unnecessary check in _strptime when determining AM/PM
New submission from Gordon P. Hemsley : Since __calc_am_pm() explicitly limits self.am_pm to 2 values, there are only ever 3 possible values of %p: AM, PM, or blank. Since blank is treated the same as AM, there is only the need to check whether %p is PM. This eliminates an unnecessary comparison and doubly ensures that there is no unhandled case. -- messages: 342872 nosy: gphemsley, p-ganssle priority: normal severity: normal status: open title: Eliminate unnecessary check in _strptime when determining AM/PM versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36959] ISO date errors in _strptime are jumbled
Gordon P. Hemsley added the comment: Ah yes, to be clear, I wasn't trying to suggest that the error messages themselves were wrong—just that they weren't triggering when the tests were expecting them to. Some of the existing tests currently trigger the "unconverted data remains" ValueError from earlier in the method, but because the messages are not checked, that is not immediately obvious. I've also added new tests for additional scenarios that would presumably also be considered invalid, based on the existing ones. -- ___ Python tracker <https://bugs.python.org/issue36959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36959] ISO date errors in _strptime are jumbled
Gordon P. Hemsley added the comment: I've created a PR that fixes the issue, which I discovered while evaluating the test coverage for _strptime. Certain scenarios of error messages were never being hit because the cascade was out of order, and the tests were not showing that because they were throwing a different ValueError than the one they were expecting to throw. -- ___ Python tracker <https://bugs.python.org/issue36959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36959] ISO date errors in _strptime are jumbled
Change by Gordon P. Hemsley : -- keywords: +patch pull_requests: +13319 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36959] ISO date errors in _strptime are jumbled
New submission from Gordon P. Hemsley : This has not been apparent because the tests for this code are not testing what they think they're testing. -- components: Library (Lib), Tests messages: 342810 nosy: gphemsley priority: normal severity: normal status: open title: ISO date errors in _strptime are jumbled versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23012] RuntimeError: settrace/setprofile function gets lost
Change by Gordon P. Hemsley : -- nosy: +gphemsley ___ Python tracker <https://bugs.python.org/issue23012> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36474] RecursionError resets trace function set via sys.settrace
Change by Gordon P. Hemsley : -- nosy: +gphemsley ___ Python tracker <https://bugs.python.org/issue36474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10933] Tracing disabled when a recursion error is triggered (even if properly handled)
Change by Gordon P. Hemsley : -- nosy: +gphemsley ___ Python tracker <https://bugs.python.org/issue10933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36954] test_recursive_repr breaks tracing in test_xml_etree
New submission from Gordon P. Hemsley : When running test_xml_etree with tracing, e.g. when running test coverage, tracing breaks after the execution of test_recursive_repr. -- components: Tests messages: 342783 nosy: blueyed, gphemsley, serhiy.storchaka priority: normal pull_requests: 13311 severity: normal status: open title: test_recursive_repr breaks tracing in test_xml_etree versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36954> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36684] codecov.io code coverage has not updated since 2019-04-13
Change by Gordon P. Hemsley : -- pull_requests: +13059 ___ Python tracker <https://bugs.python.org/issue36684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36684] codecov.io code coverage has not updated since 2019-04-13
Gordon P. Hemsley added the comment: Hah, that's indeed where I've landed in my experimentation. -- ___ Python tracker <https://bugs.python.org/issue36684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36684] codecov.io code coverage has not updated since 2019-04-13
Gordon P. Hemsley added the comment: It seems the primary cause of the problem is simply that testing crossed the boundary of maximum execution time allotted by Travis CI. I'm experimenting now with ways to speed up testing without losing granularity. However, given how long code coverage has been missing, it might be worthwhile to move forward on a stopgap solution that at least gets code coverage being tracked again, if not comprehensively. -- ___ Python tracker <https://bugs.python.org/issue36684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element
Gordon P. Hemsley added the comment: It seems the final open question on this is whether the mismatch between the Python and C implementations is enough to bypass PendingDeprecationWarning for copy() in favor of jumping straight to DeprecationWarning. -- ___ Python tracker <https://bugs.python.org/issue32424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36684] codecov.io code coverage has not updated since 2019-04-13
Gordon P. Hemsley added the comment: Testing has shown that the gcc build itself runs fine. The problem appears to be with how the coverage tests are run. -- ___ Python tracker <https://bugs.python.org/issue36684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element
Change by Gordon P. Hemsley : -- pull_requests: +12918 ___ Python tracker <https://bugs.python.org/issue32424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36685] C implementation of xml.etree.ElementTree does not make a copy of attrib argument when creating new Element
Change by Gordon P. Hemsley : -- keywords: +patch pull_requests: +12823 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue36685> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element
Change by Gordon P. Hemsley : -- pull_requests: +12822 ___ Python tracker <https://bugs.python.org/issue32424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36684] codecov.io code coverage has not updated since 2019-04-13
Gordon P. Hemsley added the comment: I'm not sure when the gcc build started failing, but it looks like the commits at the boundary failed due to max build time. Something is apparently too slow to run. -- ___ Python tracker <https://bugs.python.org/issue36684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36684] codecov.io code coverage has not updated since 2019-04-13
Gordon P. Hemsley added the comment: It looks like this may be the result of the code coverage being provided by the optional gcc build, which has been failing for quite a while. -- ___ Python tracker <https://bugs.python.org/issue36684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36684] codecov.io code coverage has not updated since 2019-04-13
Gordon P. Hemsley added the comment: In fact, it seems the last commit on master was 962b028b0c20abcf39594f08b1e5f8c36c4e5f6f 3 months ago, which doesn't even have valid report. The previous commit, 9932a22897ef9905161dac7476e6976370e13515, was the last to have a functioning report. -- ___ Python tracker <https://bugs.python.org/issue36684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element
Gordon P. Hemsley added the comment: Opened issue36685 for discussion of the attrib copy issue. -- ___ Python tracker <https://bugs.python.org/issue32424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36685] C implementation of xml.etree.ElementTree does not make a copy of attrib argument when creating new Element
Gordon P. Hemsley added the comment: My proposed solution to this was to make a copy of the attrib dictionary in the create_new_element() method in the C implementation, which solves the problem. However, this was apparently objected to on the grounds of performance. Not knowing C very well, any guidance on a better way to fix this would be appreciated. :) -- ___ Python tracker <https://bugs.python.org/issue36685> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36685] C implementation of xml.etree.ElementTree does not make a copy of attrib argument when creating new Element
New submission from Gordon P. Hemsley : In the process of investigating and writing tests for issue32424, I discovered that the C implementation of xml.etree.ElementTree does not make a copy of the attrib argument when creating a new element, allowing the attributes of the element to be modified outside of creation. The Python implementation does not have this problem. -- components: Library (Lib), XML messages: 340590 nosy: asvetlov, eli.bendersky, gphemsley, mdk, p-ganssle, r.david.murray, scoder, serhiy.storchaka, thatiparthy priority: normal severity: normal status: open title: C implementation of xml.etree.ElementTree does not make a copy of attrib argument when creating new Element type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue36685> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element
Gordon P. Hemsley added the comment: Taking a step back, I want to make sure I understand the action items for resolving this: * Add copy() as an alias to __copy__() in the C implementation to match the Python implementation. * Deprecate copy() in favor of copy.copy() in both the Python and C implementations, bypassing a PendingDeprecation step because the implementations have been out of sync for so long as it is. Any other issues discussed here are orthogonal to the goal of this ticket. Are we in agreement on this? -- versions: +Python 3.8, Python 3.9 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue32424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36684] codecov.io code coverage has not updated since 2019-04-13
New submission from Gordon P. Hemsley : The last commit available on codecov.io is from a week ago (d28aaa7df8bcd46f4135d240d041b0b171b664cc): https://codecov.io/gh/python/cpython And the widget on the README is showing a status of "unknown". -- messages: 340588 nosy: gphemsley priority: normal severity: normal status: open title: codecov.io code coverage has not updated since 2019-04-13 ___ Python tracker <https://bugs.python.org/issue36684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element
Gordon P. Hemsley <gphems...@gphemsley.org> added the comment: >> As discussed above, starting with msg309074, __deepcopy__() is being added >> to the Python implementation because it already exists in the C >> implementation. > > Python implementation shouldn't copy all implementation details of the C > implementation. This is cumbersome and often impossible. Both implementation > should have the same behavior, and they do have. As it stands, calling Element.__deepcopy__() will succeed with the C implementation and fail with the Python implementation. That seems problematic to me, and making that *not* be the case is trivial, so I don't understand the generalization to "all implementation details". Additionally, if copy.deepcopy() already works well with the Python implementation, why would it not work on the C implementation? What is different about the C implementation that requires the definition of __deepcopy__() in the first place? >> And additional tests have in fact uncovered further discrepancies between >> the Python and C implementations with regard to copying behavior. > > What are these discrepancies? As I mentioned in the PR, the C implementation does not make use of Element.__init__() when it creates new instances of the class, opting instead to use create_new_element() (which is not used in the C implementation of Element.__init__()). However, create_new_element() does not make a copy of the attrib dict that is passed in, meaning that the internal attrib dict of an Element instance is mutable by changing the dict that was passed in. I have modified the C implementation to fix this problem by adding a copy line in create_new_element(). Without this change, some of the new tests in the PR will fail in the C implementation. The Python implementation does not have this problem because it inherently always goes through Element.__init__(). > In any case it is better to extend existing tests by adding missed checks > than duplicate tests. As I mentioned in the PR: I have added the unit tests in the way that I have because the existing checks are generally integration tests, and most of the test coverage for this module comes as a side effect of pickle tests. It is my goal to expand the unit tests later to test each method individually, so starting that work here makes it easier. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32466] Remove fractions._gcd()
Gordon P. Hemsley <gphems...@gphemsley.org> added the comment: So, if I'm understanding your position correctly: * We're back to needing a test for the line in question. * We're eschewing the possibility of changing the behavior of `fractions.Fraction` to force int numerator and denominator. Is that correct? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32466] Remove fractions._gcd()
Gordon P. Hemsley <gphems...@gphemsley.org> added the comment: Side note: https://github.com/aleaxit/gmpy/issues/127 suggests that the types in question were added to the numeric tower for gmpy 2.0.9 and 2.1.0. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32466] Remove fractions._gcd()
Gordon P. Hemsley <gphems...@gphemsley.org> added the comment: Indeed, that is the code fragment I was referring to. Mathematically speaking, a rational number is one that can be expressed as a fraction of two integers, so in that regard the numerator and the denominator should both be integers. But let's assume for argument's sake that a type comes through where the numerator and the denominator are fractions: 1/2 and 2/3, respectively. This code would normalize them by cross-multiplying: numerator = 1 * 3 = 3 denominator = 2 * 3 = 6 Now they are both integers. In what scenario would the numerator and denominator be numbers.Rational but not an integer or a fraction? If someone could even come up with one, would it be worthwhile to allow as a fraction? And on the flip side, if math.gcd() only accepts integers and not, at least, numbers.Integral, wouldn't that be a bug? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32466] Remove fractions._gcd()
New submission from Gordon P. Hemsley <gphems...@gphemsley.org>: I noticed that there was a single line of Lib/fractions.py that did not have test coverage: the normalize step for fractions with non-integer numerators and/or denominators. I initially was going to implement a test for that line, but upon further reflection, I cannot envision a scenario where that would be possible. The code already requires its initial parameters to be numbers.Rational and then normalizes their numerators and denominators to be integers. So, instead, I propose to remove this check, first introduced in issue22486, and to roll the fractions._gcd() function up into the deprecated fractions.gcd(). -- components: Library (Lib), Tests messages: 309288 nosy: gphemsley, mark.dickinson, rhettinger priority: normal severity: normal status: open title: Remove fractions._gcd() versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element
Gordon P. Hemsley <gphems...@gphemsley.org> added the comment: As discussed above, starting with msg309074, __deepcopy__() is being added to the Python implementation because it already exists in the C implementation. And additional tests have in fact uncovered further discrepancies between the Python and C implementations with regard to copying behavior. PR 5046 has changes that I believe are ready for review. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element
Gordon P. Hemsley <gphems...@gphemsley.org> added the comment: Given the discussion, I've gone ahead and created a new PR that synchronizes the three copy methods between implementations and deprecates Element.copy(). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element
Change by Gordon P. Hemsley <gphems...@gphemsley.org>: -- title: Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation -> Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32424> ___ ___ 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
Change by Gordon P. Hemsley <gphems...@gphemsley.org>: -- pull_requests: +4927 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32424> ___ ___ 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 <gphems...@gphemsley.org> 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 <rep...@bugs.python.org> <https://bugs.python.org/issue32424> ___ ___ 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 <gphems...@gphemsley.org> 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 <rep...@bugs.python.org> <https://bugs.python.org/issue32424> ___ ___ 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
Change by Gordon P. Hemsley <gphems...@gphemsley.org>: -- keywords: +patch pull_requests: +4909 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28236] In xml.etree.ElementTree Element can be created with empty and None tag
Gordon P. Hemsley <gphems...@gphemsley.org> added the comment: Issues of potential relevance to this discussion: * Issue28237 - In xml.etree.ElementTree bytes tag or attributes raises on serialization * Issue5166 - ElementTree and minidom don't prevent creation of not well-formed XML -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28236> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29209] Remove old-deprecated ElementTree features
Change by Gordon P. Hemsley <gphems...@gphemsley.org>: -- nosy: +gphemsley ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29209> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32425] Allow non-default XML parsers to take advantage of a _parse_whole definition in xml.etree.ElementTree.ElementTree.parse()
Gordon P. Hemsley <gphems...@gphemsley.org> added the comment: Sorry, the chunks are 64 KiB. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32425> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32425] Allow non-default XML parsers to take advantage of a _parse_whole definition in xml.etree.ElementTree.ElementTree.parse()
New submission from Gordon P. Hemsley <gphems...@gphemsley.org>: Currently, ElementTree.parse() in xml.etree.ElementTree only invokes _parse_whole() on the parser if no parser is specified and it falls back to the built-in XMLParser. This has two drawbacks: * If the built-in XMLParser is specified explicitly, it does not get the advantage of using its _parse_whole() method. * If another XML parser is specified, it does not have the option to define a _parse_whole() method. In both cases, the parser parses in chunks (of 16 KiB), which is potentially slower. I propose allowing any parser to take advantage of _parse_whole() if it has defined such a method. (This would also have the benefit of eliminating some minor code duplication--two return branches could become one.) -- components: Library (Lib), XML messages: 309011 nosy: eli.bendersky, gphemsley, scoder priority: normal severity: normal status: open title: Allow non-default XML parsers to take advantage of a _parse_whole definition in xml.etree.ElementTree.ElementTree.parse() type: enhancement versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32425> ___ ___ 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
New submission from Gordon P. Hemsley <gphems...@gphemsley.org>: 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 <rep...@bugs.python.org> <https://bugs.python.org/issue32424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28236] In xml.etree.ElementTree Element can be created with empty and None tag
Gordon P. Hemsley <gphems...@gphemsley.org> added the comment: To be clear, we are talking about the Element class of the ElementTree module, which is distinct from the ElementTree class of the same module. That said, I personally question the implementation decision to represent things like treating comments as an Element with a tag of a Comment function. The XML standard is pretty clear that neither comments nor processing instructions are in fact elements, and I don't see it as a Good Thing that arbitrary objects are allowed as the value of tag, unless there is a requirement that such objects are subclasses of str. Note also that the documentation makes no mention of tag being anything other than a string. And there is inconsistency with where bytes are supposedly allowed (according to the documentation) and where they're actually allowed (according to the code). Given this, I think it's hard to say what user code is expected to make use of. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28236> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28236] In xml.etree.ElementTree Element can be created with empty and None tag
Gordon P. Hemsley <gphems...@gphemsley.org> added the comment: I disagree. This library is meant to be an interface onto XML syntax, and XML has pretty strict requirements on syntax. As msg277125 shows, you're liable to get very far downstream before the error becomes apparent. In addition, I'm finding a number of internal inconsistencies, both between the docs and the code and between the Python code and the C code, that demonstrate that doing these type checks up front would be beneficial to the entire library. (Note: The C code also does not do them.) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28236> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20291] Argument Clinic should understand *args and **kwargs parameters
Change by Gordon P. Hemsley <gphems...@gphemsley.org>: -- nosy: +gphemsley ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28236] In xml.etree.ElementTree Element can be created with empty and None tag
Gordon P. Hemsley <gphems...@gphemsley.org> added the comment: I decided to take a look at this, since it seems easy... At first glance, this would appear to be a straightforward change--the docs state in multiple places that Element() takes a string as its tag argument. But it turns out that a lot of internal functionality depends on passing in non-strings as the tag value. -- nosy: +gphemsley ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28236> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
