Stefan Behnel added the comment:
FWIW, it seems reasonable to have a protocol for this.
--
___
Python tracker
<https://bugs.python.org/issue38225>
___
___
Pytho
Stefan Behnel added the comment:
I think we did it wrong in issue 17582. Parser behaviour is not a reason why
the *serialisation* should modify the content.
Luckily, fixing this does not impact the C14N serialisation (which aims to
guarantee byte identical serialisation), but it changes
Stefan Behnel added the comment:
Not so quick. :) You're probably aware of the details, but still, let me state
clearly what this is about, to make sure that we're all on the same page here.
(I'm also asking in Serhiy, because he did quite some work on ET in the past
and has experience
Stefan Behnel added the comment:
Agreed that both should behave the same.
And, we should finally decide whether this should really be changed or not. The
current behaviour is counter-intuitive, but it's been like that forever and
lots of code depends on it in one way or another, so
Change by Stefan Behnel :
--
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
I think setting "xml:base" from ElementInclude is worth another ticket.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8
___
Pyt
Stefan Behnel added the comment:
New changeset c6a7bdb356835c9d7513b1ea6846683d446fe6c3 by Stefan Behnel in
branch 'master':
bpo-20928: support base-URL and recursive includes in etree.ElementInclude
(#5723)
https://github.com/python/cpython/commit/c6a7bdb356835c9d7513b1ea6846683d446fe6c3
Stefan Behnel added the comment:
Duplicate of issue 9521 (and issue 24287).
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> xml.etree.ElementTree skips processing instructions when parsing
___
Py
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
> along with the appropriate CO_COROUTINE flag set
No, it never did that, for safety reasons. It's difficult to say if enabling
these flags is the right thing to do, because it's unclear what assumptions
code that tests for them would make. In CPython its
Stefan Behnel added the comment:
My usual first reaction is: "if you need to find out whether the return value
of a callable will be an Awaitable or not, without calling it, then you're
probably doing something wrong in your design".
However,
a) there is code that tries th
Change by Stefan Behnel :
--
keywords: -patch
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
New changeset b65be6cd3d9b6102227d27f4f35385f999a7dd7d by Stefan Behnel (Miss
Islington (bot)) in branch '3.8':
bpo-38158: Removing nonexistant member "doc" from PyType_Spec documentation
(GH-16142) (GH-16154)
https://github.com/python/cpyt
Stefan Behnel added the comment:
I think access to the global module state is the most critical for an
extension, probably by far. A direct pointer to the interpreter state from
every type feels like an optimisation that may be premature at this point.
Modules should have that reference
Stefan Behnel added the comment:
Absolutely, Tahia. It just needs a PR with a doc update.
--
___
Python tracker
<https://bugs.python.org/issue38158>
___
___
Change by Stefan Behnel :
--
stage: -> needs patch
___
Python tracker
<https://bugs.python.org/issue38158>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Stefan Behnel :
The current documentation of the PyType_Spec struct lists a "doc" member which
does not exist. It should be removed from the docs.
https://docs.python.org/3.8/c-api/type.html#c.PyType_Spec
--
assignee: docs@python
components: Documentatio
Stefan Behnel added the comment:
New changeset 195dc142f84804ad9c8ce91414ab4a0bf9615f09 by Stefan Behnel (Miss
Islington (bot)) in branch '3.7':
bpo-33187: Document ElementInclude (XInclude) support in ElementTree (GH-8861)
(GH-15972)
https://github.com/python/cpython/commit
Change by Stefan Behnel :
--
versions: +Python 3.7
___
Python tracker
<https://bugs.python.org/issue33187>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
New changeset 6cf0ba8a632b1c0bd3576ed33c971ca3778000de by Stefan Behnel (Miss
Islington (bot)) in branch '3.8':
bpo-33187: Document ElementInclude (XInclude) support in ElementTree (GH-8861)
(GH-15958)
https://github.com/python/cpython/commit
Stefan Behnel added the comment:
New changeset 97b817eae34b77be1ced382e15098a112f547848 by Stefan Behnel (Anjali
Bansal) in branch 'master':
bpo-33187: Document ElementInclude (XInclude) support in ElementTree (GH-8861)
https://github.com/python/cpython/commit
Change by Stefan Behnel :
--
versions: -Python 3.7
___
Python tracker
<https://bugs.python.org/issue33187>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Behnel :
--
versions: +Python 3.9 -Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<https://bugs.python.org/issue33187>
___
___
Python-bug
Stefan Behnel added the comment:
Arguably, writing out "b'x'" as attribute name instead of raising an exception
isn't ideal. However, OTOH, I think it's reasonable to accept anything that is
serialisable as a string, not just strings. That makes it difficult to draw a
line.
I
Stefan Behnel added the comment:
I agree that it's surprising to get a low-level parser error from a high-level
library like xmlrpc. I think this can be changed without deprecation, because
users must expect exceptions from the xmlrpc library in any case.
Targeting to Py3.9, needs patch
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
New changeset 7d952ded6813c896ea3f4234bb8db5247dcb5484 by Stefan Behnel (Gordon
P. Hemsley) in branch 'master':
bpo-32424: Deprecate xml.etree.ElementTree.Element.copy() in favor of
copy.copy() (GH-12995)
https://github.com/python/cpython/commit
Stefan Behnel added the comment:
Let's just deprecate it directly (in Py3.9, I guess), given that it was never
documented.
--
___
Python tracker
<https://bugs.python.org/issue32
Stefan Behnel added the comment:
I don't see anything inherently wrong with having multiple text nodes.
In fact, input with very large text content can be considered a security threat
(c.f. compression bombs), so a tool like pulldom (which is designed for
incremental processing) should
Stefan Behnel added the comment:
I agree that formatting is not a use case by itself. I like the idea of XPath
grepping, though, especially *without* pretty printing, i.e. one result per
line.
I admit that there is no strong reason for adding such a command line tool to
the stdlib, though
Stefan Behnel added the comment:
Already fixed in later versions of the documentation:
https://docs.python.org/3/library/xml.etree.elementtree.html#supported-xpath-syntax
Note that Py3.4 is no longer maintained.
--
resolution: -> out of date
stage: -> resolved
status
Stefan Behnel added the comment:
Sounds like a good idea to add something like this.
Have a look here for some more ideas:
https://github.com/lxml/lxml/blob/master/tools/xpathgrep.py
ElementTree should be able to provide most of these features as well these days.
--
stage: -> ne
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
New changeset b5d3ceea48c181b3e2c6c67424317afed606bd39 by Stefan Behnel in
branch 'master':
bpo-14465: Add an indent() function to xml.etree.ElementTree to pretty-print
XML trees (GH-15200)
https://github.com/python/cpython/commit
Stefan Behnel added the comment:
FWIW, makes total sense to me to have it there. Question is more if we can
still get it into Py3.8, since it's a new feature for fractions.
--
nosy: +lukasz.langa, scoder
___
Python tracker
<ht
Stefan Behnel added the comment:
Right. If you want to compare XML trees for equality, either write your own
deep-tree comparison function, or use something like doctestcompare, or use a
C14N serialisation (which is now part of Py3.8). Whichever suits your needs.
https://github.com/lxml
Stefan Behnel added the comment:
FWIW, deep traversing an XML tree on an operation as simple as "==" seems
excessive. To me, object identity comparison seems the most sensible behaviour
of "==" on Element objects.
(It's not "complicated to implement", bu
Change by Stefan Behnel :
--
pull_requests: +14929
pull_request: https://github.com/python/cpython/pull/15200
___
Python tracker
<https://bugs.python.org/issue14
Stefan Behnel added the comment:
The spec section that Raymond quoted makes it clear that pretty printing is not
for everyone. But there are many use cases where it is 1) helpful, 2) leads to
correct results, and 3) does not grow the file size excessively. Whoever wants
to make use
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
New changeset bb697899aa65d90488af1950ac7cceeb3877d409 by Stefan Behnel in
branch '3.8':
[3.8] bpo-37399: Correctly attach tail text to the last element/comment/pi
(GH-14856) (GH-14936)
https://github.com/python/cpython/commit
Stefan Behnel added the comment:
New changeset 63673916464bace8e2147357395fdf3497967ecb by Stefan Behnel (Miss
Islington (bot)) in branch '3.8':
[3.8] bpo-34160: explain how to deal with attribute order in ElementTree
(GH-14867) (GH-14935)
https://github.com/python/cpython/commit
Change by Stefan Behnel :
--
pull_requests: +14709
pull_request: https://github.com/python/cpython/pull/14936
___
Python tracker
<https://bugs.python.org/issue37
Stefan Behnel added the comment:
New changeset a3697db0102b9b6747fe36009e42f9b08f0c1ea8 by Stefan Behnel in
branch 'master':
bpo-34160: explain how to deal with attribute order in ElementTree (GH-14867)
https://github.com/python/cpython/commit/a3697db0102b9b6747fe36009e42f9b08f0c1ea8
Stefan Behnel added the comment:
New changeset c6cb4cdd21c0c3a09b0617dbfaa7053d3bfa6def by Stefan Behnel in
branch 'master':
bpo-37399: Correctly attach tail text to the last element/comment/pi (GH-14856)
https://github.com/python/cpython/commit/c6cb4cdd21c0c3a09b0617dbfaa7053d3bfa6def
Jesse Ibarra schrieb am 22.07.19 um 18:12:
> On Saturday, July 20, 2019 at 1:11:51 PM UTC-6, Stefan Behnel wrote:
>> Jesse Ibarra schrieb am 20.07.19 um 04:12:
>>> Sorry, I am not understanding. Smalltlak VW 8.3 does not support Python.
>>> I can only call Pyhto
Stefan Behnel added the comment:
> Changing the major version number itself is a breaking change
So is the proposed change, in a way. At some point, there will be a 4.0
release, which may or may not break the code in question. So, testing for
"version_info[0] == 3" is already w
Jesse Ibarra schrieb am 20.07.19 um 04:12:
> Sorry, I am not understanding. Smalltlak VW 8.3 does not support Python.
> I can only call Pyhton code through C/Python API.
Ok, but that doesn't mean you need to write code that uses the C-API of
Python. All you need to do is:
1) Start up a CPython
Stefan Behnel added the comment:
I created a PR that adds a couple of paragraphs to the documentation. Comments
welcome.
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue34
Change by Stefan Behnel :
--
pull_requests: +14654
pull_request: https://github.com/python/cpython/pull/14867
___
Python tracker
<https://bugs.python.org/issue34
Jesse Ibarra schrieb am 17.07.19 um 20:39:
> My options seem rather limited, I need to make a Pipeline from
> (Smalltalk -> C -> Python) then go back (Smalltalk <- C <- Python).
> Since Smalltalk does not support Python directly I have to settle with
> the C/Python API
>
Change by Stefan Behnel :
--
keywords: +patch
pull_requests: +14646
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14856
___
Python tracker
<https://bugs.python.org/issu
Stefan Behnel added the comment:
No need to keep this bug open on CPython side. The backwards compatibility has
been restored (and I'll release Cython 0.29.12 today to resolve the issue on
that side.)
--
resolution: -> fixed
status: open ->
Stefan Behnel added the comment:
> it should not be rely upon
IMHO, the correct behaviour under coverage analysis is to keep the code and not
discard it. After all, it is code that exists, and that is not being executed,
so it should count as uncovered code. The fact that some Pyt
Stefan Behnel added the comment:
> Is it part of Cython 0.29.11 released yesterday?
Yes.
--
___
Python tracker
<https://bugs.python.org/issue37221>
___
_
Stefan Behnel added the comment:
I'm working on a patch. It's not entirely trivial, so it might take a couple of
days.
--
assignee: -> scoder
___
Python tracker
<https://bugs.python.org/issu
Stefan Behnel added the comment:
I think it might be this call that strikes here:
https://github.com/python/cpython/commit/43851a202c#diff-f3b827d6e1d5c270ab42bc2c0523c1d2R2842
treebuilder_flush_data() is not made for concatenating text, it simply replaces
it. If both text parts come
Stefan Behnel added the comment:
I'm really only waiting for bpo-37250 to be resolved, then I can prepare a new
point release of Cython, preferably this week.
--
___
Python tracker
<https://bugs.python.org/issue37
Stefan Behnel added the comment:
Thank you, Petr, for bringing this discussion back on a solid basis, actually
twice already.
And sorry for causing this problem in the first place. The "tp_print = 0" was
necessary to fix misbehaviour in Py2, and we should have restricted it to
Stefan Behnel added the comment:
I agree with Steve that broadly redefining a global name in a widely used
header file is not a good idea. You never know what names users have in their
code. Yes, you can work around it by undef-ing it again, but honestly, in that
case, both sides are hacks
Stefan Behnel added the comment:
(I forgot to state the obvious third option, which is: don't do anything and
leave everything as it is now in beta-1.)
--
___
Python tracker
<https://bugs.python.org/issue37
Stefan Behnel added the comment:
> they can equally easily zero out the entire structure and ignore it without
> changing behavior on any Python 3.x.
Any solution that we apply in Cython will require users to regenerate their .c
sources with a new Cython version in order to make it c
Stefan Behnel added the comment:
Note that PyCode_New() is not the only change in 3.8 beta1 that breaks Cython
generated code. The renaming of "tp_print" to "tp_vectorcall" is equally
disruptive, because Cython has (or had) a work-around for CPython
(mis-)behaviour
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
New changeset 18e23f227be59241cbb1eeb6d6669771dd7275fb by Stefan Behnel (Miss
Islington (bot)) in branch '3.7':
bpo-18911: clarify that the minidom XML writer receives texts but not bytes
(GH-13718)
https://github.com/python/cpython/commit
Change by Stefan Behnel :
--
resolution: fixed ->
stage: resolved -> backport needed
status: closed -> open
versions: +Python 3.7
___
Python tracker
<https://bugs.python.or
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8 -Python 2.7, Python 3.5, Python 3.6
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
New changeset 5ac0b988fd5f1428efe35329c531c7b5c74d37f6 by Stefan Behnel
(Windson yang) in branch 'master':
bpo-18911: clarify that the minidom XML writer receives texts but not bytes
(GH-13352)
https://github.com/python/cpython/commit
Stefan Behnel added the comment:
Asking users unconditionally to use the "xmlcharrefreplace" replacement method
seems wrong for UTF-8. It should not be necessary.
We should, however, document explicitly that the file will receive text and not
bytes, i.e. that users are
Stefan Behnel added the comment:
I'm closing this old ticket. Python 2 will be dead by the time someone gets
around to do something about it.
--
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Python tracke
Stefan Behnel added the comment:
I'm really sorry again, but I only consulted the XML spec on this now (and also
the way libxml2 does it), and I found that XML comment text actually does not
get escaped. It's not character data, and, in fact, "--" is not even allowed at
Change by Stefan Behnel :
--
title: Clean up makeunicode.py script -> Make makeunicode.py script more
readable
___
Python tracker
<https://bugs.python.org/issu
Change by Stefan Behnel :
--
keywords: +patch
pull_requests: +13154
___
Python tracker
<https://bugs.python.org/issue36885>
___
___
Python-bugs-list mailin
New submission from Stefan Behnel :
The code generation in the makeunicode.py script is more difficult to read than
necessary due to the many use of "print(file=fp)" everywhere. Moving the "file"
argument out of the way makes it easier to read through the actual code that
Stefan Behnel added the comment:
Hmm, sorry, I was wrong here. I looked it up and also checked the behaviour of
other libraries: the data content of PIs is application specific and must not
be escaped, at all. It's not XML character data.
Sorry for the confusion and the extra work on your
Stefan Behnel added the comment:
I think this is resolved by issue 36673 (Py3.8). Please try it in the just
released alpha4.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bug
Stefan Behnel added the comment:
PR welcome. This is how lxml implements it:
https://lxml.de/api.html#cdata
Tests are here:
https://github.com/lxml/lxml/blob/1a2db33aa8b9619c1caf407167567d5cca0b9019/src/lxml/tests/test_etree.py#L1692-L1749
I guess it won't look perfectly the same
Stefan Behnel added the comment:
New changeset e9a465f3ea22c61e05ffe7b44a69102b25f57db4 by Stefan Behnel in
branch 'master':
bpo-36676: Update what's new document. (#13226)
https://github.com/python/cpython/commit/e9a465f3ea22c61e05ffe7b44a69102b25f57db4
Change by Stefan Behnel :
--
pull_requests: +13136
___
Python tracker
<https://bugs.python.org/issue36676>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Behnel :
--
stage: needs patch -> resolved
___
Python tracker
<https://bugs.python.org/issue36831>
___
___
Python-bugs-list mailing list
Un
Stefan Behnel added the comment:
Sorry for the annoyance during the release.
--
keywords: -patch
resolution: -> fixed
stage: patch review -> needs patch
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
New changeset 88db8bd0648588c67eeab16d0bc72ec5c206e3ad by Stefan Behnel in
branch 'master':
bpo-36831: Do not apply default namespace to unprefixed attributes in
ElementPath. (#13201)
https://github.com/python/cpython/commit
Change by Stefan Behnel :
--
keywords: +patch
pull_requests: +13112
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Stefan Behnel added the comment:
Right, thanks for the reproducer. The default namespace should not apply to
attributes. I'll write up a PR today.
--
___
Python tracker
<https://bugs.python.org/issue36
Change by Stefan Behnel :
--
nosy: -scoder
___
Python tracker
<https://bugs.python.org/issue25541>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Looks like the issue was originally reported against Python 3.4.
--
___
Python tracker
<https://bugs.python.org/issue25
Stefan Behnel added the comment:
Thanks for the report. In simple cases like this, I think it's fine to comment
in the original ticket and/or pull request. There's no real need for a
dedicated ticket, at least not before an official release.
--
resolution: -> fixed
stage: pa
Stefan Behnel added the comment:
New changeset 6b95149eccac540a911a5ada03fcb7d623a0de37 by Stefan Behnel in
branch 'master':
bpo-36811: Fix a C compiler warning in _elementtree.c. (GH-13109)
https://github.com/python/cpython/commit/6b95149eccac540a911a5ada03fcb7d623a0de37
Change by Stefan Behnel :
--
keywords: +patch
pull_requests: +13024
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36811>
___
___
Py
Stefan Behnel added the comment:
FWIW, I think it's equally reasonable to allow assignment expressions directly
in f-strings, as it is to require parentheses with a reference to the
invalidity of top-level expressions.
That makes me lean towards adding a parse-time error message
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
New changeset 47541689ccea79dfcb055c6be5800b13fcb6bdd2 by Stefan Behnel in
branch 'master':
bpo-28238: Implement "{*}tag" and "{ns}*" wildcard tag selection support for
ElementPath, and extend the surrounding tests and docs. (GH-12997
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
> Maybe complete Doc/license.rst?
Thanks, done.
--
___
Python tracker
<https://bugs.python.org/issue13611>
___
___
Python-
Change by Stefan Behnel :
--
pull_requests: +12972
___
Python tracker
<https://bugs.python.org/issue13611>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
I'm generally ok with such APIs. It seems needless to require
@lru_cache()
def f(): ...
when a simple decorator would suffice. I think I might decide otherwise in
cases where almost all usages require arguments, but if the no-arguments case
is common
Stefan Behnel added the comment:
A buildbot failure made me notice that the test files were not part of the
CPython installation yet, so I added them. I also took the opportunity to add a
README file that describes where they come from and under which conditions they
were originally
Stefan Behnel added the comment:
New changeset 0d5864fa07ab4f03188c690a5eb07bdd1fd1cb9c by Stefan Behnel in
branch 'master':
bpo-13611: Include C14N 2.0 test data in installation (GH-13053)
https://github.com/python/cpython/commit/0d5864fa07ab4f03188c690a5eb07bdd1fd1cb9c
Stefan Behnel added the comment:
Ok, I think it's reasonable to make the resource management explicit for the
specific case of letting iterparse() open the file. That suggests that there
should also be context manager support, given that safe usages would often
involve a try-finally.
Since
201 - 300 of 3085 matches
Mail list logo
