[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element
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/7d952ded6813c896ea3f4234bb8db5247dcb5484 -- ___ 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
[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element
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/issue32424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38011] xml.dom.pulldom splits text data at buffer size when parsing from file
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 not start collecting more content than the user asked for. Getting multiple text nodes in some cases seems an ok-ish price to pay. A documentation PR is welcome. -- assignee: -> docs@python components: +Documentation nosy: +docs@python versions: +Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38011> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37940] Add xml.tool to pretty print XML like json.tool
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. -- ___ Python tracker <https://bugs.python.org/issue37940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23423] XPath Support in ElementTree doc omission
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: open -> closed ___ Python tracker <https://bugs.python.org/issue23423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37940] Add xml.tool to pretty print XML like json.tool
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: -> needs patch ___ Python tracker <https://bugs.python.org/issue37940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14465] xml.etree.ElementTree: add feature to prettify XML output
Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue14465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14465] xml.etree.ElementTree: add feature to prettify XML output
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/b5d3ceea48c181b3e2c6c67424317afed606bd39 -- ___ Python tracker <https://bugs.python.org/issue14465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37819] as_integer_ratio() missing from fractions.Fraction()
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 <https://bugs.python.org/issue37819> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity
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/lxml/blob/master/src/lxml/doctestcompare.py https://docs.python.org/3.8/library/xml.etree.elementtree.html#xml.etree.ElementTree.canonicalize -- ___ Python tracker <https://bugs.python.org/issue37792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity
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", but rather can be very expensive to execute.) Regarding your other questions (and note that this is a bug tracker, so discussing unrelated questions in a ticket is inappropriate – use the Python mailing list instead if you want): "SubElement" suggests a constructor, yes. It kind-of makes sense, given what it does, and resembles "Element", which is the constructor for a (non-sub) Element. It might seem funny, sure, but on the other hand, why should users be bothered with the implementation detail that it is a function? :-) "fromstringlist()" matches "tostringlist()", API-wise. Both are probably not very widely used, but I don't see much value in removing them. It always breaks someone's code out there. -- ___ Python tracker <https://bugs.python.org/issue37792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14465] xml.etree.ElementTree: add feature to prettify XML output
Change by Stefan Behnel : -- pull_requests: +14929 pull_request: https://github.com/python/cpython/pull/15200 ___ Python tracker <https://bugs.python.org/issue14465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14465] xml.etree.ElementTree: add feature to prettify XML output
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 of it is probably in such a situation. I think adding some kind of support in the standard library would be nice, but it should not hurt "normal" uses, especially when a lot of data is involved. I'll send a PR that adds an indent() function to pre-process trees. Comments welcome. -- assignee: serhiy.storchaka -> scoder versions: +Python 3.9 -Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue14465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[Cython] Progress towards Cython 3.0
Hi, tl;dr: help with the remaining work would be appreciated. The "3.0" milestone on github currently lists 24 open tickets, so there's still quite a bit to do before the release. Some of them are already PRs that need more work in one way or another. https://github.com/cython/cython/milestone/58 The upside is that we've already closed twice as many issues as are still open. https://github.com/cython/cython/issues?utf8=✓=is%3Aclosed+type%3Aissue+milestone%3A3.0 I went through the open issues and marked everything as "blocker" that represents behavioural changes. We should make sure to include those in this release, or postpone them to the next major release. https://github.com/cython/cython/issues?utf8=%E2%9C%93=is%3Aopen+label%3A%22P%3A+blocker%22+milestone%3A3.0 Some tickets seem easy to do (marked as "good first issue"). But also the "binding" PR is a big one that will need some more fiddling with the details, some of which can be investigated separately. https://github.com/cython/cython/pull/2864 Any help with the open issues would be greatly appreciated. Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Python-Dev] Re: Comparing dict.values()
Kristian Klette schrieb am 23.07.19 um 22:59:
> During the sprints after EuroPython, I made an attempt at adding support for
> comparing the results from `.values()` of two dicts.
>
> Currently the following works as expected:
>
> ```
> d = {'a': 1234}
>
> d.keys() == d.keys()
> d.items() == d.items()
> ```
>
> but `d.values() == d.values()` does not return the expected
> results. It always returns `False`. The symmetry is a bit off.
>
> In the bug trackers[0] and the Github PR[1], I was asked
> to raise the issue on the python-dev mailing list to find
> a consensus on what comparing `.values()` should do.
>
> I'd argue that Python should compare the values as expected here,
> or if we don't want to encourage that behaviour, maybe we should
> consider raising an exception.
> Returning just `False` seems a bit misleading.
>
> What are your thoughts on the issue?
FWIW, after reading most of this thread, I do not like the idea of raising
an exception for an innocent comparison. Just think of a list of arbitrary
objects, including a dict values view for some reason, and you're looking
for the right object in the list. Maybe in some kind of generic tool,
decorator, iter-helper, or whatever, something that has to deal with
arbitrary objects provided by random users, which uses "in" instead of a
loop with "is" comparisons.
I also kind-of like the idea of having
d.values() == d.values()
return True and otherwise let the comparison return False for everything
else. This seems to be the only reasonable behaviour that might(!) have a
use case, maybe in the same line as the argument above. I can't really see
a reason for implementing anything more than that.
Stefan
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/CGRTXKDHS7GBBZY5GQ6ZM2FAVHPHJBAQ/
[issue37399] XML text behaviour change if there are comments
Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37399] XML text behaviour change if there are comments
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/bb697899aa65d90488af1950ac7cceeb3877d409 -- ___ Python tracker <https://bugs.python.org/issue37399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34160] ElementTree not preserving attribute order
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/63673916464bace8e2147357395fdf3497967ecb -- ___ Python tracker <https://bugs.python.org/issue34160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37399] XML text behaviour change if there are comments
Change by Stefan Behnel : -- pull_requests: +14709 pull_request: https://github.com/python/cpython/pull/14936 ___ Python tracker <https://bugs.python.org/issue37399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34160] ElementTree not preserving attribute order
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 -- ___ Python tracker <https://bugs.python.org/issue34160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37399] XML text behaviour change if there are comments
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 -- ___ Python tracker <https://bugs.python.org/issue37399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Embedding Python in C
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 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 runtime from Smalltalk (see the embedding example I >> posted) and make it import an extension module that you write (e.g. using >> the "inittab" mechanism [1]). >> >> 2) Use Cython to implement this extension module to provide an interface >> between your Smalltalk code and your Python code. Use the Smalltalk C-API >> from your Cython code to call into Smalltalk and exchange data with it. >> >> Now you can execute Python code inside of Python and make it call back and >> forth into your Smalltalk code, through the interface module. And there is >> no need to use the Python C-API for anything beyond step 1), which is about >> 5 lines of Python C-API code if you write it yourself. Everything else can >> be implemented in Cython and Python. >> >> Stefan >> >> >> [1] >> https://docs.python.org/3/extending/embedding.html?highlight=PyImport_appendinittab#extending-embedded-python > > This cleared so much @Stefan, thank you. I just need some clarification if > you don't mind. > > In (1), when you say "import an extension module that you write", do you > mean the Python library that was created "import emb"? Is that gonna be > written in Cython or standalone .C file? Yes. In Cython. > in (2), what do to mean when you said "Use the Smalltalk C-API from your > Cython code to call into Smalltalk and exchange data with it."? Not sure what part exactly you are asking about, but you somehow have to talk to the Smalltalk runtime from your Cython/Python code if you want to interact with it. I assume that this will be done through the C API that Smalltalk provides. Just in case, did you check if there is already a bridge for your purpose? A quick web search let me find this, not sure if it helps. https://github.com/ObjectProfile/PythonBridge Stefan -- https://mail.python.org/mailman/listinfo/python-list
[issue37636] Deprecate slicing and ordering operations on sys.version
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 wrong, because that code almost certainly wants to know if it runs in Py2 and not if it runs in Py3. It's better fixed soon, before we get too close to Py4, and I think a deprecation notice could be helpful for that. Preferably for as many of the non-future-proof spellings as possible. -- nosy: +scoder ___ Python tracker <https://bugs.python.org/issue37636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Embedding Python in C
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 runtime from Smalltalk (see the embedding example I posted) and make it import an extension module that you write (e.g. using the "inittab" mechanism [1]). 2) Use Cython to implement this extension module to provide an interface between your Smalltalk code and your Python code. Use the Smalltalk C-API from your Cython code to call into Smalltalk and exchange data with it. Now you can execute Python code inside of Python and make it call back and forth into your Smalltalk code, through the interface module. And there is no need to use the Python C-API for anything beyond step 1), which is about 5 lines of Python C-API code if you write it yourself. Everything else can be implemented in Cython and Python. Stefan [1] https://docs.python.org/3/extending/embedding.html?highlight=PyImport_appendinittab#extending-embedded-python -- https://mail.python.org/mailman/listinfo/python-list
[issue34160] ElementTree not preserving attribute order
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/issue34160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34160] ElementTree not preserving attribute order
Change by Stefan Behnel : -- pull_requests: +14654 pull_request: https://github.com/python/cpython/pull/14867 ___ Python tracker <https://bugs.python.org/issue34160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Embedding Python in C
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 > (https://docs.python.org/3.6/extending/embedding.html#beyond-very-high-level-embedding-an-overview). > Any suggestions? First of all: don't use the C-API! :-) Use Cython instead. It's a Python-to-C compiler that covers up all the ugly little details of talking to Python from C (importing a module is just "import module", and it even adapts to different Python versions automatically). You can keep writing Python code, and at the same time trivially use external C code. https://cython.org/ http://docs.cython.org/en/latest/src/tutorial/ For embedding Python in an external program (in case you really need to do that and can't live with starting Python instead of Smalltalk), here's an example: https://github.com/cython/cython/tree/master/Demos/embed It uses the "--embed" argument to Cython that generates a C (main) function to start up the CPython runtime. Stefan -- https://mail.python.org/mailman/listinfo/python-list
[issue37399] XML text behaviour change if there are comments
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/issue37399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37221] PyCode_New API change breaks backwards compatibility policy
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 -> closed ___ Python tracker <https://bugs.python.org/issue37221> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?
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 Python versions can detect at compile time that it will never be executed, and thus discard it ahead of time, should not have an impact on the coverage analysis. -- nosy: +scoder ___ Python tracker <https://bugs.python.org/issue37500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37221] PyCode_New API change breaks backwards compatibility policy
Stefan Behnel added the comment: > Is it part of Cython 0.29.11 released yesterday? Yes. -- ___ Python tracker <https://bugs.python.org/issue37221> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37399] XML text behaviour change if there are comments
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/issue37399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [Cython] Backport language_level=2 fix?
Jeroen Demeyer schrieb am 27.06.19 um 12:44: > Since Cython 3.0 doesn't seem close to being released, is there any chance > to backport https://github.com/cython/cython/pull/2792 > > It's a fairly simple and reasonable bugfix. Done: https://github.com/cython/cython/commit/d019d9f3e057cae5f873280bf78bce639f2a81da Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[issue37399] XML text behaviour change if there are comments
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 separately, and the comment between the two is discarded, then the last one overwrites the first one. -- ___ Python tracker <https://bugs.python.org/issue37399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37221] PyCode_New API change breaks backwards compatibility policy
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/issue37221> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
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 Py2 back then (that line has been there since late 2013). I think keeping some kind of a "tp_print" named field in PyTypeObject for now is the best we can do. I like Jeroen's PR (thanks for taking care of so many things at a time, Jeroen!), and I think we should just go with it. I'm happy to release a new point release for Cython, as soon as it's clear what CPython will do, and how Cython can detect the change to adapt to it. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [Cython] Empty defines of Py_TPFLAGS_METHOD_DESCRIPTOR?
Jeroen Demeyer schrieb am 18.06.19 um 13:47: > What's the purpose of commit > https://github.com/cython/cython/commit/8ac1a6a55fc44ff858cc367af556250a91f71d16 > > I can't think of any reasonable scenario where Py_TPFLAGS_METHOD_DESCRIPTOR > would be defined differently than in CPython (i.e. with value 1<<17). > > This is an honest question, I don't know what I'm missing. We define a couple of CPython flag names for older versions, and some of them are defined as 0 instead of their bit value, because we are not using them ourselves and it gives '&' tests an obvious 0 result. We don't define this one specifically, but I wanted to allow this kind of empty definition for the flag, that's all. Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
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. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [Cython] Reason for __Pyx_PyObject_Call2Args, __Pyx_PyObject_Call3Args
Jeroen Demeyer schrieb am 13.06.19 um 15:14: > Is there any particular reason why Cython has specific code like > __Pyx_PyObject_Call2Args, __Pyx_PyObject_Call3Args, ... > > And then there is even more complicated Python code in PyMethodCallNode > generating something like __Pyx_PyObject_Call2Args for an arbitrary number > of arguments. > > This could be simplified a lot by just writing code once to deal with n > arguments and then letting the C compiler do the clever stuff: if you write > a loop where the number of iterations is a small compile-time constant, the > compiler should unroll it. > > I checked that GCC-6.4.0 is able to do this and the much simpler code with > a for loop is as efficient as the current code. But maybe there are other > compilers that don't do this (or there used to be such compilers when that > code was written)? > > I stumbled on this while working on > https://github.com/cython/cython/issues/2996 It was originally written that way because there were slight differences, and only 0/1 args were special cased initially. The method optimisation then showed that it's worth special casing the self argument, which gave rise to the other helpers. I've seen your PR, which cleans this up very nicely. Thanks! Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
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/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset
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 compile in Py3.8. The main decision point in this ticket is: should they need to or not? Everything else is just minor technicalities. (I didn't bring up this topic, but the question is up on the table now.) > I have no problem changing the names of deprecated/reserved fields in > PyTypeObject between releases. Source compatibility guarantees do not extend > that far. Fair enough, and I'm ok with letting CPython move forward cleanly and break things that are easily fixed on user side. My point is that it makes no sense to justify bpo-37221 with the goal of not breaking Cython modules, when at the same time another change (the one discussed here) has already broken them. Either we find a striking justification for bpo-37221 that *excludes* Cython generated modules, or we take back *both* changes and restore full source code compatibility. Everything in between is just causing useless code churn and annoyance on all sides. -- ___ Python tracker <https://bugs.python.org/issue37250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[Python-Dev] Re: Expected stability of PyCode_New() and types.CodeType() signatures
Victor Stinner schrieb am 12.06.19 um 00:09: > So yeah, the PyCode_New() change is very annoying in practical, since > every single project using Cython requires a new release in practice. I think Cython's deal with regard to this is: """ If you use Cython, we will try hard to cover up the adaptations for upcoming (and existing) CPython versions for you. But you'll likely have to rerun Cython on your project before a new CPython major release comes out. """ That's obviously not ideal for projects that end up being unmaintained. But then again, you can't freeze time forever, and /any/ change to a dependency can end up being fatal to them. I personally think that rerunning Cython when a new CPython release comes out is an acceptable price to pay for a project. In the worst case, this can even be done by others, as you suggested as a common Fedora practice elsewhere, Victor. (To be fair, I'll have to add that new Cython versions are also part of those dependencies that might end up introducing incompatible changes and forcing your code to be adapted. The upcoming Cython 3.0 release will be such a case. However, given our compatibility record so far, I still consider Cython a very fair deal.) Stefan ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4J3ZPCLJBHLPJRT32X2JIBAQ3C7OAL5H/
[Python-Dev] Re: Expected stability of PyCode_New() and types.CodeType() signatures
Neil Schemenauer schrieb am 08.06.19 um 22:46: > It would be great if we had a system that did CI testing with the > top PyPI modules. E.g. pull the latest versions of the top 100 PyPI > modules and test them with the latest CPython branch. FWIW, travis-ci provides the latest CPython master builds (and some latest dev branches). We use them in Cython for our CI tests. One of the problems is that their images include some widely used libraries like NumPy, some of which in turn depend on Cython these days, so it happened once already that they failed to provide updated images because they were lacking a Cython version that worked with them, and we didn't notice that a change in Cython was needed because the CI builds were continuing to use an outdated CPython master version. :) Ah, circular dependencies… I think they fixed something about that, though. It wasn't a problem this time, at least. We also have the "Cython testbed", which we (irregularly) use before releases to check that we didn't break more than was broken before the release. https://travis-ci.org/cython-testbed It's pretty much what was asked for here, just for Cython, and it turns out to be a considerable amount of work to keep this from breaking arbitrarily for the included projects, even without changing something in Cython along the way. Thus, personally, I would prefer a decentralised CI approach, where interested/important projects test themselves against CPython master (which many of them do already), and have them report back when they notice an undermotivated breakage. Some projects do that with Cython (and CPython) already, and that works quite well so far and seems the least work for everyone. Stefan ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EOGBRUUGY7PGUUONITJYFNIHURQ5E4OK/
[issue37221] PyCode_New API change breaks backwards compatibility policy
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 that reset the field explicitly to NULL after calling PyType_Ready(), which could set it arbitrarily without good reason. So, either revert that field renaming, too, or ignore Cython generated modules for the reasoning about the change in this ticket. I'm fine with keeping things as they are now in beta-1, but we could obviously adapt to whatever beta-2 wants to change again. -- ___ Python tracker <https://bugs.python.org/issue37221> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36885] Make makeunicode.py script more readable
Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [Python-Dev] Expected stability of PyCode_New() and types.CodeType() signatures
Serhiy Storchaka schrieb am 01.06.19 um 09:02: > I have a related proposition. Yesterday I have reported two bugs (and Pablo > quickly fixed them) related to handling positional-only arguments. These > bugs were occurred due to subtle changing the meaning of co_argcount. When > we make some existing parameters positional-only, we do not add new > arguments, but mark existing parameters. But co_argcount now means the only > number of positional-or-keyword parameters. Most code which used > co_argcount needs now to be changed to use co_posonlyargcount+co_argcount. > > I propose to make co_argcount meaning the number of positional parameters > (i.e. positional-only + positional-or-keyword). This would remove the need > of changing the code that uses co_argcount. Sounds reasonable to me. The main distinction points are positional arguments vs. keyword arguments vs. local variables. Whether the positional ones are positional or positional-only is irrelevant in many cases. > PyCode_New() can be kept unchanged, but we can add new PyCode_New2() or > PyCode_NewEx() with different signature. It's not a commonly used function, and it's easy for C code to adapt. I don't think it's worth adding a new function to the C-API here, compared to just changing the signature. Very few users would benefit, at the cost of added complexity. Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[issue18911] minidom does not encode correctly when calling Document.writexml
Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue18911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18911] minidom does not encode correctly when calling Document.writexml
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/18e23f227be59241cbb1eeb6d6669771dd7275fb -- ___ Python tracker <https://bugs.python.org/issue18911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18911] minidom does not encode correctly when calling Document.writexml
Change by Stefan Behnel : -- resolution: fixed -> stage: resolved -> backport needed status: closed -> open versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue18911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18911] minidom does not encode correctly when calling Document.writexml
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.org/issue18911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18911] minidom does not encode correctly when calling Document.writexml
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/5ac0b988fd5f1428efe35329c531c7b5c74d37f6 -- ___ Python tracker <https://bugs.python.org/issue18911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18911] minidom does not encode correctly when calling Document.writexml
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 themselves responsible for opening the output file with the desired encoding. We should also make it clearer that the "encoding" argument to writexml() does not change that. -- ___ Python tracker <https://bugs.python.org/issue18911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[python-committers] discussion fragmentation
Paul Moore schrieb am 15.05.19 um 17:18: > I don't really follow this sort of PR discussion, as the github > emails don't tend to have sufficient context on what's being said I agree, although there is also an upside to it. PR discussions can be more easily constrained to reflect the exact reasoning behind the specific change, whereas more general PEP discussions, especially in mailing list threads, are more likely to cover broader (sets of) topics and/or get distracted and jump between topics. So that's an improvement, I think. Not every PEP change is easy to discuss as a PR, though. > multiple fragmented forums for discussion. It > feels a lot harder these days to keep track of all the > discussions/decisions going on. +1 Discussions easily get out of the scope of a PEP PR or the original topic, which makes it impossible to know when something relevant happens to get discussed in one of a dozen places that can be used to discuss them. E-mail threads obviously have the same problem, but at least they are still part of the same mailing list, so subject changes are relatively easy to detect when … the subject changes. Same for conferences, they are great for discussing complex topics and working together to improve the understanding of a matter, but then someone has to sit down and write up the outcomes so that the general discussion can start (or continue) in the public places. I would prefer a sort of an "open first" principle, where things are discussed on python-dev (Python) or python-committers (processes), unless there is a reason not to (such as PRs, SIGs, voting, …). That gives everyone a good handle to stop a discussion and say "let's move this to place X". More generally, there needs to be a simple scheme or checklist that makes it easy to detect when a discussion should be moved elsewhere, and preferably to which place exactly. At least for the 80% case. Stefan ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[issue3020] doctest should have lib2to3 integration
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 tracker <https://bugs.python.org/issue3020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33303] ElementTree Comment text isn't escaped
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 all inside of comments. (Funny enough, the HTML serialiser does escaping for both comments and PIs, but, well, that's HTML, I guess…) https://www.w3.org/TR/REC-xml/#sec-comments Sorry, Jeffrey, I should have looked that up in the spec much earlier, before you invested so much time into this. There are two disallowed cases: "--" in the text content, and "-" at the end of the text (which would lead to an "--->"). Now, the thing is, such validation is currently unprecedented in ElementTree, so I don't know if we should start raising exceptions from the serialiser for this case, and if yes, which. Since comments are rare, it won't hurt performance to do that, but once we get started on this, users would probably also want their text and attribute content and their tag and attribute names to be validated, and that would hurt then. So, I will have to reject the PR and this ticket. -- resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36885] Make makeunicode.py script more readable
Change by Stefan Behnel : -- title: Clean up makeunicode.py script -> Make makeunicode.py script more readable ___ Python tracker <https://bugs.python.org/issue36885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36885] Clean up makeunicode.py script
Change by Stefan Behnel : -- keywords: +patch pull_requests: +13154 ___ Python tracker <https://bugs.python.org/issue36885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36885] Clean up makeunicode.py script
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 is being generated. -- components: Demos and Tools messages: 342171 nosy: benjamin.peterson, scoder priority: low severity: normal stage: patch review status: open title: Clean up makeunicode.py script type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33303] ElementTree Comment text isn't escaped
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 side. -- ___ Python tracker <https://bugs.python.org/issue33303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34600] python3 regression ElementTree.iterparse() unable to capture comments
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://bugs.python.org/issue34600> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36874] Support CDATA by xml.etree.(c)ElementTree
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 in ElementTree in the end, but it might be enough to implement a string wrapper class (or even str subclass?), and then maybe special-case it in the serialiser (probably needed for the escaping). However, anything that relieves the serialiser from doing special work for this exceptional case might be a good idea. -- stage: -> needs patch versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue36874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36676] Make ET.XMLParser target aware of namespace prefixes
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 -- ___ Python tracker <https://bugs.python.org/issue36676> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [Python-Dev] PEP 580/590 discussion
Petr Viktorin schrieb am 10.05.19 um 00:07: > On 5/9/19 5:33 PM, Jeroen Demeyer wrote: >> Maybe you misunderstood my proposal. I want to allow both for extra >> flexibility: >> >> - METH_FASTCALL (possibly combined with METH_KEYWORDS) continues to work >> as before. If you don't want to care about the implementation details of >> vectorcall, this is the right thing to use. >> >> - METH_VECTORCALL (using exactly the vectorcallfunc signature) is a new >> calling convention for applications that want the lowest possible >> overhead at the cost of being slightly harder to use. > > Then we can, in the spirit of minimalism, not add METH_VECTORCALL at all. > [...] > METH_FASTCALL is currently not documented, and it should be renamed before > it's documented. Names with "fast" or "new" generally don't age well. I personally don't see an advantage in having both, apart from helping code that wants to be fast also on Py3.7, for example. It unnecessarily complicates the CPython implementation and C-API. I'd be ok with removing FASTCALL in favour of VECTORCALL. That's more code to generate for Cython in order to adapt to Py<3.6, Py3.6, Py3.7 and then Py>=3.[89], but well, seeing the heap of code that we *already* generate, it's not going to hurt our users much. It would, however, be (selfishly) helpful if FASTCALL could still go through a deprecation period, because we'd like to keep the current Cython 0.29.x release series compatible with Python 3.8, and I'd like to avoid adding support for VECTORCALL and compiling out FASTCALL in a point release. Removing it in Py3.9 seems ok to me. Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[issue36676] Make ET.XMLParser target aware of namespace prefixes
Change by Stefan Behnel : -- pull_requests: +13136 ___ Python tracker <https://bugs.python.org/issue36676> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36831] ElementTree.find attribute matching with empty namespace
Change by Stefan Behnel : -- stage: needs patch -> resolved ___ Python tracker <https://bugs.python.org/issue36831> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36831] ElementTree.find attribute matching with empty namespace
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.org/issue36831> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36831] ElementTree.find attribute matching with empty namespace
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/88db8bd0648588c67eeab16d0bc72ec5c206e3ad -- ___ Python tracker <https://bugs.python.org/issue36831> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36831] ElementTree.find attribute matching with empty namespace
Change by Stefan Behnel : -- keywords: +patch pull_requests: +13112 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue36831> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36831] ElementTree.find attribute matching with empty namespace
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/issue36831> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25541] Wrong usage of sockaddr_un struct for abstract namespace unix sockets
Change by Stefan Behnel : -- nosy: -scoder ___ Python tracker <https://bugs.python.org/issue25541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25541] Wrong usage of sockaddr_un struct for abstract namespace unix sockets
Stefan Behnel added the comment: Looks like the issue was originally reported against Python 3.4. -- ___ Python tracker <https://bugs.python.org/issue25541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36811] Warning when compiling _elementree.c
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: patch review -> resolved status: open -> closed type: -> compile error ___ Python tracker <https://bugs.python.org/issue36811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36811] Warning when compiling _elementree.c
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 -- ___ Python tracker <https://bugs.python.org/issue36811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36811] Warning when compiling _elementree.c
Change by Stefan Behnel : -- keywords: +patch pull_requests: +13024 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36798] f-strings do not support top-level :=
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 that suggests the right way to do it, and leave it out as a feature for now, because it risks conflicting with ":" as format separator. We do not know yet if we will really need this feature. It's easier to add the feature later, than to remove it again in case we find that it gets in the way more than it helps. -- nosy: +scoder ___ Python tracker <https://bugs.python.org/issue36798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28238] In xml.etree.ElementTree findall() can't search all elements in a namespace
Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue28238> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28238] In xml.etree.ElementTree findall() can't search all elements in a namespace
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)
https://github.com/python/cpython/commit/47541689ccea79dfcb055c6be5800b13fcb6bdd2
--
___
Python tracker
<https://bugs.python.org/issue28238>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30485] Element.findall(path, dict) doesn't insert null namespace
Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue30485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13611] Integrate ElementC14N module into xml.etree package
Stefan Behnel added the comment: > Maybe complete Doc/license.rst? Thanks, done. -- ___ Python tracker <https://bugs.python.org/issue13611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13611] Integrate ElementC14N module into xml.etree package
Change by Stefan Behnel : -- pull_requests: +12972 ___ Python tracker <https://bugs.python.org/issue13611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36772] Let lru_cache be used as a decorator with no arguments
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 (and there is no ambiguity in the arguments), then I prefer not requiring parentheses. -- nosy: +scoder ___ Python tracker <https://bugs.python.org/issue36772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13611] Integrate ElementC14N module into xml.etree package
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 provided by the W3C (IANAL, but basically free use with copyright notice). https://www.w3.org/Consortium/Legal/2015/doc-license Is there anything else I have to take care of when adding externally provided/licensed files to the source tree? -- ___ Python tracker <https://bugs.python.org/issue13611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13611] Integrate ElementC14N module into xml.etree package
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 -- ___ Python tracker <https://bugs.python.org/issue13611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25707] Add the close method for ElementTree.iterparse() object
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 it might not always be obvious for users when they need to close the iterator or not, I would also suggest to not let it raise an error on a double-close, i.e. if .close() was already called or the iterator was already exhausted (and the file closed automatically), calling .close() should just do nothing. -- ___ Python tracker <https://bugs.python.org/issue25707> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13611] Integrate ElementC14N module into xml.etree package
Change by Stefan Behnel : -- pull_requests: +12971 ___ Python tracker <https://bugs.python.org/issue13611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36673] Comment/PI parsing support for ElementTree
Change by Stefan Behnel : -- pull_requests: -12811 ___ Python tracker <https://bugs.python.org/issue36673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13611] Integrate ElementC14N module into xml.etree package
Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue13611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36676] Make ET.XMLParser target aware of namespace prefixes
Change by Stefan Behnel : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36676> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13611] Integrate ElementC14N module into xml.etree package
Stefan Behnel added the comment: New changeset e1d5dd645d5f59867cb0ad63179110f310cbca89 by Stefan Behnel in branch 'master': bpo-13611: C14N 2.0 implementation for ElementTree (GH-12966) https://github.com/python/cpython/commit/e1d5dd645d5f59867cb0ad63179110f310cbca89 -- ___ Python tracker <https://bugs.python.org/issue13611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36676] Make ET.XMLParser target aware of namespace prefixes
Stefan Behnel added the comment: New changeset dde3eebdaa8d2c51971ca704d53af7cbcda8bb34 by Stefan Behnel in branch 'master': bpo-36676: Namespace prefix aware parsing support for the ET.XMLParser target (GH-12885) https://github.com/python/cpython/commit/dde3eebdaa8d2c51971ca704d53af7cbcda8bb34 -- ___ Python tracker <https://bugs.python.org/issue36676> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36673] Comment/PI parsing support for ElementTree
Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36673] Comment/PI parsing support for ElementTree
Stefan Behnel added the comment: New changeset 43851a202cabce1e6be699e7177735c778b6697e by Stefan Behnel in branch 'master': bpo-36673: Implement comment/PI parsing support for the TreeBuilder in ElementTree. (#12883) https://github.com/python/cpython/commit/43851a202cabce1e6be699e7177735c778b6697e -- ___ Python tracker <https://bugs.python.org/issue36673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13611] Integrate ElementC14N module into xml.etree package
Stefan Behnel added the comment: Thanks for testing, Zackery. I resolved the reference leaks. They were already in the PR for issue 36676. Both PRs updated. -- ___ Python tracker <https://bugs.python.org/issue13611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13611] Integrate ElementC14N module into xml.etree package
Stefan Behnel added the comment: > I personally think it's ready to go into the last alpha release Since I didn't get any negative comments or requests for deferral, I'll merge this today to get the feature into the last (still unreleased) alpha. We still have the beta phase to resolve issues with it. -- ___ Python tracker <https://bugs.python.org/issue13611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13611] Integrate ElementC14N module into xml.etree package
Stefan Behnel added the comment:
Playing around with it a bit more, I ended up changing the interface of the
canonicalize() function to return its output as a string by default. It's
really nice to be able to say
c14n_xml = canonicalize(plain_xml)
To write to a file, you now do this:
with open("c14n_output.xml", mode='w', encoding='utf-8') as out_file:
canonicalize(xml_data, out=out_file)
and to read from a file:
canonicalize(from_file=fileobj)
I think that nicely handles all use cases.
--
___
Python tracker
<https://bugs.python.org/issue13611>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28238] In xml.etree.ElementTree findall() can't search all elements in a namespace
Stefan Behnel added the comment:
BTW, I found that lxml and ET differ in their behaviour when searching for '*'.
ET takes it as meaning "any tree node", whereas lxml interprets it as "any
Element". Since ET's parser does not create comments and processing
instructions by default, this does not make a difference in most cases, but
when the tree contains comments or PIs, then they will be found by '*' in ET
but not in lxml.
At least for "{*}*", they now both return only Elements. Changing either
behaviour for '*' is probably not a good idea at this point.
--
___
Python tracker
<https://bugs.python.org/issue28238>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28238] In xml.etree.ElementTree findall() can't search all elements in a namespace
Stefan Behnel added the comment: PR submitted, feedback welcome. -- assignee: -> scoder type: behavior -> enhancement ___ Python tracker <https://bugs.python.org/issue28238> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28238] In xml.etree.ElementTree findall() can't search all elements in a namespace
Change by Stefan Behnel : -- keywords: +patch pull_requests: +12919 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue28238> ___ ___ 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
Stefan Behnel added the comment: New changeset 50fed0b64faa305338ef5607b570fe209de6 by Stefan Behnel (Gordon P. Hemsley) in branch 'master': bpo-32424: Improve test coverage for xml.etree.ElementTree (GH-12891) https://github.com/python/cpython/commit/50fed0b64faa305338ef5607b570fe209de6 -- ___ 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
[issue21403] cElementTree's Element creation handles attrib argument different from ET
Stefan Behnel added the comment: Let's not change this in Py2 anymore. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue21403> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
