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
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
Change by Gordon P. Hemsley :
--
nosy: +gphemsley
___
Python tracker
<https://bugs.python.org/issue10933>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Gordon P. Hemsley :
--
nosy: +gphemsley
___
Python tracker
<https://bugs.python.org/issue23012>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Gordon P. Hemsley :
--
nosy: +gphemsley
___
Python tracker
<https://bugs.python.org/issue36474>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Change by Gordon P. Hemsley :
--
keywords: +patch
pull_requests: +13319
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36959>
___
_
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
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 remai
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
Change by Gordon P. Hemsley :
--
keywords: +patch
pull_requests: +13338
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36967>
___
_
Change by Gordon P. Hemsley :
--
components: +Library (Lib)
___
Python tracker
<https://bugs.python.org/issue36967>
___
___
Python-bugs-list mailing list
Unsub
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:
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
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
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
Gordon P. Hemsley added the comment:
Opened issue36685 for discussion of the attrib copy issue.
--
___
Python tracker
<https://bugs.python.org/issue32
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 r
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/issue36
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
&
Change by Gordon P. Hemsley :
--
pull_requests: +12822
___
Python tracker
<https://bugs.python.org/issue32424>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Gordon P. Hemsley :
--
keywords: +patch
pull_requests: +12823
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Gordon P. Hemsley :
--
pull_requests: +12918
___
Python tracker
<https://bugs.python.org/issue32424>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/issue36
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
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 cov
Gordon P. Hemsley added the comment:
Hah, that's indeed where I've landed in my experimentation.
--
___
Python tracker
<https://bugs.python.o
Change by Gordon P. Hemsley :
--
pull_requests: +13059
___
Python tracker
<https://bugs.python.org/issue36684>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gordon P. Hemsley 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 im
Gordon P. Hemsley 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
Change by Gordon P. Hemsley :
--
nosy: +gphemsley
___
Python tracker
<https://bugs.python.org/issue20291>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gordon P. Hemsley 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
Gordon P. Hemsley 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
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
New submission from Gordon P. Hemsley :
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
Gordon P. Hemsley added the comment:
Sorry, the chunks are 64 KiB.
--
___
Python tracker
<https://bugs.python.org/issue32425>
___
___
Python-bugs-list mailin
Change by Gordon P. Hemsley :
--
nosy: +gphemsley
___
Python tracker
<https://bugs.python.org/issue29209>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gordon P. Hemsley 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
Change by Gordon P. Hemsley :
--
keywords: +patch
pull_requests: +4909
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32424>
___
_
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
<ht
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 P
Change by Gordon P. Hemsley :
--
pull_requests: +4927
___
Python tracker
<https://bugs.python.org/issue32424>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Gordon P. Hemsley :
--
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
<
Gordon P. Hemsley 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
<https://bugs.py
Gordon P. Hemsley 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
New submission from Gordon P. Hemsley :
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
Gordon P. Hemsley 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 assum
Gordon P. Hemsley 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
<https://bugs.python.org/issue32
Gordon P. Hemsley 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.
49 matches
Mail list logo
