[issue33303] ElementTree Comment text isn't escaped

Stefan Behnel added the comment: Yes, comment text should be escaped internally like all other text, not by the user. The same applies to processing instructions. This suggests that it's probably also untested currently. Could you provide a PR for that changes both and adds tests

[issue8583] Hardcoded namespace_separator in the cElementTree.XMLParser

Stefan Behnel added the comment: Closing as a duplicate of the more general issue 18304. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> ElementTree -- provide a way to ignore namespace in tags a

[issue25707] Add the close method for ElementTree.iterparse() object

Stefan Behnel added the comment: I don't think there is a need for a close() method. Instead, the iterator should close the file first thing when it's done with it, but only if it owns it. Therefore, the fix in issue 25688 seems correct. Closing can also be done explicitly in a finaliser

[issue35502] Memory leak in xml.etree.ElementTree.iterparse

Stefan Behnel added the comment: This ticket looks like it's done for 3.7/8. Can it be closed? I guess 3.6 isn't relevant anymore, right? -- ___ Python tracker <https://bugs.python.org/issue35

[issue28460] Minidom, order of attributes, datachars

Stefan Behnel added the comment: I'll close this as a duplicate of issue 34160. I'm aware that you also proposed to reduce the text escaping, but it's still needed for attribute values. Not sure if it's really worth having two different escape functions. Feel free to provide a PR and create

[issue9521] xml.etree.ElementTree skips processing instructions when parsing

Change by Stefan Behnel : -- Removed message: https://bugs.python.org/msg340994 ___ Python tracker <https://bugs.python.org/issue9521> ___ ___ Python-bugs-list m

[issue9521] xml.etree.ElementTree skips processing instructions when parsing

Stefan Behnel added the comment: Issue 24287 is a duplicate of this one and has some additional discussion. -- ___ Python tracker <https://bugs.python.org/issue9

[issue32235] test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205

Stefan Behnel added the comment: Closing as outdated / third-party. -- nosy: +scoder stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/i

[issue35502] Memory leak in xml.etree.ElementTree.iterparse

Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.6 ___ Python tracker <https://bugs.python.or

[issue18304] ElementTree -- provide a way to ignore namespace in tags and searches

Stefan Behnel added the comment: Coming back to this issue after a while, I think it's still a relevant problem in some use cases. However, it's not currently clear what an improved solution would look like. The fully qualified tag names in Clark notation are long, sure, but also extremely

[issue24287] Let ElementTree prolog include comments and processing instructions

Stefan Behnel added the comment: This is a duplicate of 9521, but it's difficult to say which ticket is better. -- ___ Python tracker <https://bugs.python.org/issue24

[issue18304] ElementTree -- provide a way to ignore namespace in tags and searches

Stefan Behnel added the comment: I was referring to issue 28238 and issue 30485. -- ___ Python tracker <https://bugs.python.org/issue18304> ___ ___ Python-bug

[issue5166] ElementTree and minidom don't prevent creation of not well-formed XML

Stefan Behnel added the comment: This is a tricky decision. lxml, for example, validates user input, but that's because it has to process it anyway and does it along the way directly on input (and very efficiently in C code). ET, on the other hand, is rather lenient about what it allows

[issue24287] Let ElementTree prolog include comments and processing instructions

Change by Stefan Behnel : -- superseder: -> xml.etree.ElementTree skips processing instructions when parsing ___ Python tracker <https://bugs.python.org/issu

[issue28460] Minidom, order of attributes, datachars

Change by Stefan Behnel : -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue28460> ___ ___

[issue9521] xml.etree.ElementTree skips processing instructions when parsing

Stefan Behnel added the comment: Ticket 24287 is a duplicate of this one and has some additional discussion. -- ___ Python tracker <https://bugs.python.org/issue9

[issue36735] minimize disk size of cross-compiled python3.6

Stefan Behnel added the comment: Make sure you use CFLAGS that limit the amount of debug data in the binaries. "-g1" in gcc should be enough to get stack traces on crashes, while reducing the binaries quite considerably compared to the default. "-g0" will give anoth

Re: [Python-Dev] Use C extensions compiled in release mode on a Python compiled in debug mode

Matthias Klose schrieb am 25.04.19 um 13:48: > Are there use cases where you only want to load *some* > debug extensions, even if more are installed? Not sure if there are _important_ use cases (that could justify certain design decisions), but I can certainly imagine using a non-debug (and

[issue16425] minidom replaceChild(new_child, old_child) removes new_child even if in another document

Stefan Behnel added the comment: Since "new_child" is inserted at least into a new place, it needs to be removed from its old place as well, so that part seems correct. The problem description does not make it clear whether or not "old_child" is handled correctly, but

[issue36735] minimize disk size of cross-compiled python3.6

Change by Stefan Behnel : -- nosy: -scoder ___ Python tracker <https://bugs.python.org/issue36735> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13611] Integrate ElementC14N module into xml.etree package

Stefan Behnel added the comment: It took me a couple of minutes longer to submit it, but it's there now. :) I'm aware that there is a lot of new code involved, covering really three new features, which makes reviewing it a non-trivial task. I personally think it's ready to go into the last

[issue9521] xml.etree.ElementTree skips processing instructions when parsing

Stefan Behnel added the comment: Comment/PI parsing in general is implemented in issue 36673. Note that there is currently no way to represent comments and PIs in the tree when they appear outside of the root element, which I think is what this ticket is about. After issue 36673 is resolved

[issue34160] ElementTree not preserving attribute order

Stefan Behnel added the comment: I implemented (most of) C14N 2.0 in issue 13611. Please give it a try if you are interested in the canonical serialisation feature. I would like to include it in Py3.8. -- ___ Python tracker <ht

[issue13611] Integrate ElementC14N module into xml.etree package

Change by Stefan Behnel : -- keywords: +patch pull_requests: +12893 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue13611] Integrate ElementC14N module into xml.etree package

Stefan Behnel added the comment: Turns out, it was not that easy. :-/ ElementTree lacks prefixes in its tree model, so they would have to be either registered globally (via register_namespace()) or come from the parser. I tried the latter since that is the most generic way when the input

Re: [Python-Dev] Any core dev event plans for EP19?

Berker Peksağ schrieb am 26.04.19 um 01:15: > Note that this year's core dev sprint will be held in London. See > https://discuss.python.org/t/2019-core-dev-sprint-location-date/489 > for the previous discussion. There are only two months between both > events, so perhaps we can leave things like

[Python-Dev] Any core dev event plans for EP19?

Hi core devs, there are several core dev events happening at the US PyCon this year, so I was wondering if we could organise something similar at EuroPython. Does anyone have any plans or ideas already? And, how many of us are planning to attend EP19 in Basel this year? Unless there's something

Re: [Python-Dev] Use C extensions compiled in release mode on a Python compiled in debug mode

Jeroen Demeyer schrieb am 24.04.19 um 09:24: > On 2019-04-24 01:44, Victor Stinner wrote: >> I would like to >> be able to run C extensions compiled in release mode on a Python >> compiled in debug mode > > That seems like a very good idea. I would certainly use the debug mode > while developing

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Stefan Behnel added the comment: We should not add anything to the implementation that we consider legacy elsewhere. Py3 has "always" used the C accelerator module instead of the Python implementation, which suggests that its interface is probably the righter one. So:

[issue36685] C implementation of xml.etree.ElementTree does not make a copy of attrib argument when creating new Element

Stefan Behnel added the comment: Given that this has probably been like this forever, and thus provably doesn't hurt very much, I would argue that it's not worth fixing this in Py3.7. Not sure about Py2.7, but I think the answer there should be a no, too. -- stage: -> needs pa

[issue36685] C implementation of xml.etree.ElementTree does not make a copy of attrib argument when creating new Element

Stefan Behnel added the comment: Instead of always copying the dict in create_new_element(), we should make sure that all code that calls that function (directly or indirectly) does so with a safely owned dict. If that means that we need to add dict copying in some other place, then that's

[issue36676] Make ET.XMLParser target aware of namespace prefixes

Change by Stefan Behnel : -- nosy: +eli.bendersky, serhiy.storchaka stage: patch review -> ___ Python tracker <https://bugs.python.org/issue36676> ___ ___ Py

[issue36676] Make ET.XMLParser target aware of namespace prefixes

Change by Stefan Behnel : -- keywords: +patch pull_requests: +12810 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36676> ___ ___ Py

[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:

[issue36676] Make ET.XMLParser target aware of namespace prefixes

Change by Stefan Behnel : -- title: Make TreeBuilder aware of namespace prefixes -> Make ET.XMLParser target aware of namespace prefixes ___ Python tracker <https://bugs.python.org/issu

[issue36676] Make TreeBuilder aware of namespace prefixes

New submission from Stefan Behnel : The XMLPullParser has 'start-ns' and 'end-ns' events, but the parser targets don't see them. They should have "start_ns()" and "end_ns()" callback methods to allow namespace prefix aware parsing. -- assignee: scoder components

[issue36673] Comment/PI parsing support for ElementTree

Change by Stefan Behnel : -- nosy: +eli.bendersky, serhiy.storchaka ___ Python tracker <https://bugs.python.org/issue36673> ___ ___ Python-bugs-list mailin

[issue36673] Comment/PI parsing support for ElementTree

Change by Stefan Behnel : -- keywords: +patch pull_requests: +12808 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue36673] Comment/PI parsing support for ElementTree

Stefan Behnel added the comment: This is related to issue9521 but not a strict duplicate, because fixing that would require actually adding comments and PIs to the tree when they are not within the root element. When they are, it's in line with the current tree model and this change will do

[issue36673] Comment/PI parsing support for ElementTree

New submission from Stefan Behnel : The TreeBuilder in xml.etree.ElementTree ignores comments and processing instructions. It should at least have a way to pass them through, even if there is not currently a way to append comments and PIs to the tree when they appear *outside* of the root

[issue30485] Element.findall(path, dict) doesn't insert null namespace

Stefan Behnel added the comment: New changeset e8113f51a8bdf33188ee30a1c038a298329e7bfa by Stefan Behnel in branch 'master': bpo-30485: Change the prefix for defining the default namespace in ElementPath from None to '' since there is existing code that uses that and it's more convenient

[issue30485] Element.findall(path, dict) doesn't insert null namespace

Stefan Behnel added the comment: I submitted a PR that changes the API back to an empty string. While lxml uses None here, an all-strings mapping is simply more convenient. I will start supporting both in lxml from the next release. Comments welcome

[issue30485] Element.findall(path, dict) doesn't insert null namespace

Change by Stefan Behnel : -- pull_requests: +12784 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue30485> ___ ___ Python-

[issue34160] ElementTree not preserving attribute order

Stefan Behnel added the comment: I rejected the (now conflicting) PR that adds a sorting option. I also sent Victor a tentative (and trivial) patch for the pungi package. -- ___ Python tracker <https://bugs.python.org/issue34

[issue28238] In xml.etree.ElementTree findall() can't search all elements in a namespace

Stefan Behnel added the comment: lxml has a couple of nice features here: - all tags in a namespace: "{namespace}*" - a local name 'tag' in any (or no) namespace: "{*}tag" - a tag without namespace: "{}tag" - all tags without namespace: "{}*"

[issue30485] Element.findall(path, dict) doesn't insert null namespace

Stefan Behnel added the comment: New changeset 3c5a858ec6a4e5851903762770fe526a46d3c351 by Stefan Behnel in branch 'master': bpo-30485: Re-allow empty strings in ElementPath namespace mappings since they might actually be harmless and unused (and thus went undetected previously). (#12830

[issue30485] Element.findall(path, dict) doesn't insert null namespace

Stefan Behnel added the comment: The script seems to generally assume that "" is a good representation for "no prefix", i.e. the default namespace, although that is IMHO more correctly represented as None. It's not very likely that this is the only script out there that m

[issue30485] Element.findall(path, dict) doesn't insert null namespace

Stefan Behnel added the comment: Interesting. Thanks for investigating this. It looks like the script "appxmanifest.py" uses an empty string as prefix for a lookup: File "D:\a\1\s\PC\layout\support\appxmanifest.py", line 407, in get_appxmanifest node = xml.find(

[issue30485] Element.findall(path, dict) doesn't insert null namespace

Change by Stefan Behnel : -- pull_requests: +12755 ___ Python tracker <https://bugs.python.org/issue30485> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13127] xml.dom.Attr.name is not labeled as read-only

Stefan Behnel added the comment: The intended interface seems to be to change .name rather than .localName, so yes, that should be documented somewhere. The implementation seems a bit funny in that a "self._localName", if set, takes precedence, but there doesn't seem to be an of

[issue31658] xml.sax.parse won't accept path objects

Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue31658] xml.sax.parse won't accept path objects

Stefan Behnel added the comment: Thanks for your contribution. -- ___ Python tracker <https://bugs.python.org/issue31658> ___ ___ Python-bugs-list mailin

[issue31658] xml.sax.parse won't accept path objects

Stefan Behnel added the comment: New changeset 929b70473829f04dedb8e802abcbd506926886e1 by Stefan Behnel (Mickaël Schoentgen) in branch 'master': bpo-31658: Make xml.sax.parse accepting Path objects (GH-8564) https://github.com/python/cpython/commit/929b70473829f04dedb8e802abcbd506926886e1

[issue31658] xml.sax.parse won't accept path objects

Stefan Behnel added the comment: PR looks good to me. Doesn't look critical enough for a backport, though. -- nosy: +scoder versions: -Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue31

[issue36227] Add default_namespace argument to xml.etree.ElementTree.tostring()

Stefan Behnel added the comment: Thank you for you contribution. -- components: +XML resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue30485] Element.findall(path, dict) doesn't insert null namespace

Stefan Behnel added the comment: I've merged the PR. It matches the implementation that has been released in lxml almost two years ago. -- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.8 -P

[issue30485] Element.findall(path, dict) doesn't insert null namespace

Stefan Behnel added the comment: New changeset e9927e1820caea01e576141d9a623ea394d43dad by Stefan Behnel in branch 'master': bpo-30485: support a default prefix mapping in ElementPath by passing None as prefix (#1823) https://github.com/python/cpython/commit

[issue36227] Add default_namespace argument to xml.etree.ElementTree.tostring()

Stefan Behnel added the comment: New changeset ffca16e25a70fd44a87b13b379b5ec0c7a11e926 by Stefan Behnel (Bernt Røskar Brenna) in branch 'master': bpo-36227: ElementTree.tostring() default_namespace and xml_declaration arguments (GH-12225) https://github.com/python/cpython/commit

Re: [Python-Dev] No longer enable Py_TRACE_REFS by default in debug build

Serhiy Storchaka schrieb am 11.04.19 um 17:30: > If reducing the Python memory footprint is an argument for disabling > Py_TRACE_REFS, it is a weak argument because there is larger overhead in > the debug build. I think what Victor is argueing is rather that we have better ways to debug memory

[issue34160] ElementTree not preserving attribute order

Stefan Behnel added the comment: This is done now. Thanks everyone who helped in discussing and implementing this change. I will leave Serhiy's last PR (adding the "sort_attrs" flag option) open for a while until I'm sure we have a better solution for comparing XML in 3.8, at whi

Re: [python-committers] Welcome Stefan Behnel to the team!

Thanks, everyone, for bringing me in! I don't have much to add to what was written here about myself recently, except that I'm happy to join, and flattered by the result of the vote. I'm currently working on some XML issues for the stdlib, I'll see where that gets us. There were a couple of

[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

Change by Stefan Behnel : -- nosy: +scoder ___ Python tracker <https://bugs.python.org/issue34396> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9883] minidom: AttributeError: DocumentFragment instance has no attribute 'writexml'

Change by Stefan Behnel : -- keywords: +patch pull_requests: +12604 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue9883> ___ ___ Py

[issue9883] minidom: AttributeError: DocumentFragment instance has no attribute 'writexml'

Stefan Behnel added the comment: Seems like a reasonable request to me, even if it hasn't been touched or re-requested for years. Funny enough, DocumentFragment is currently documented as "not implemented" (as for Entity, Notation, CDATASection, CharacterData, DOMImpl

[issue36493] Add math.midpoint(a,b) function

Stefan Behnel added the comment: I buy the YAGNI argument and won't fight for this. Thanks for your input. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue36493] Add math.midpoint(a,b) function

New submission from Stefan Behnel : I recently read a paper¹ about the difficulty of calculating the most exact midpoint between two floating point values, facing overflow, underflow and rounding errors. The intention is to assure that the midpoint(a,b) is - actually within the interval [a,b

[issue34160] ElementTree not preserving attribute order

Stefan Behnel added the comment: Thanks to the discussion that rhettinger triggered on python-dev, it seems that there is a majority accordance for considering the previous ordering "undefined but deterministic" rather than "sorted", and for making the change from

[issue36491] sum function's start optional parameter documented in help but not implemented

Stefan Behnel added the comment: Yes, duplicate of issue34637. -- ___ Python tracker <https://bugs.python.org/issue36491> ___ ___ Python-bugs-list mailin

[issue36491] sum function's start optional parameter documented in help but not implemented

Stefan Behnel added the comment: It's currently implemented as a positional argument, not a keyword argument. Thus the "/" at the end of the signature in the help text. That also suggests that it was a conscious decision, not an oversight. Personally, I'd also prefer it if it was

[issue36407] xml.dom.minidom wrong indentation writing for CDATA section

Stefan Behnel added the comment: I don't think this should be backported. Pretty-printing is not a production relevant feature, more of a "debugging, diffing and help users see what they get" kind of feature. It's good to have it fixed for the future, but we shouldn't bo

[issue36407] xml.dom.minidom wrong indentation writing for CDATA section

Stefan Behnel added the comment: Yes, this case is incorrect. Pretty printing should not change character content inside of a simple tag. The PR looks good to me. -- versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue36

Re: [Python-Dev] Replacement for array.array('u')?

Antoine Pitrou schrieb am 22.03.19 um 11:39: > On Fri, 22 Mar 2019 20:31:33 +1300 Greg Ewing wrote: >> A poster on comp.lang.python is asking about array.array('u'). >> He wants an efficient mutable collection of unicode characters >> that can be initialised from a string. > > TBH, I think anyone

[issue36233] xml ElementTree quotation marks of xml version string

Stefan Behnel added the comment: As a work-around, you can provide your own XML declaration (or not) and pass "xml_declaration=False" into ElementTree.write() to prevent it from adding one. UTF-8 encoded XML is ok without such a d

[issue36233] xml ElementTree quotation marks of xml version string

Stefan Behnel added the comment: I concur with Serhiy that the bug is in OpenCV (or its parser project), and that it is best solved there. Otherwise, we would create a dependency on a future/recent Python version for exporting XML

Re: [Python-ideas] dict.merge(d1, d2, ...) (Counter proposal for PEP 584)

Steven D'Aprano schrieb am 21.03.19 um 17:21: > On Thu, Mar 21, 2019 at 09:11:18AM -0700, Guido van Rossum wrote: > >> I don't find it easy to understand or remember that d1.update(d2) modifies >> d1 in place, while d1.merge(d2) first copies d1. >> >> Maybe the name can indicate the copying

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

Victor Stinner schrieb am 21.03.19 um 01:22: > Alternatives have been proposed like a recipe to sort node attributes > before serialization, but honestly, it's way too complex. Hm, really? Five lines of simple and obvious Python code, that provide a fast and completely Python-version agnostic

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

Ned Batchelder schrieb am 19.03.19 um 12:53: > I need to re-engineer my tests. … or sort the attributes before serialisation, or use C14N always, or change your code to create the attributes in sorted-by-name order. The new behaviour allows for a couple of ways to deal with the issue of backwards

Re: [Python-Dev] Is XML serialization output guaranteed to be bytewise identical forever?

Nathaniel Smith schrieb am 19.03.19 um 00:15: > That seems potentially simpler to implement than canonical XML > serialization C14N is already implemented for ElementTree, just needs to be ported to Py3.8 and merged. https://bugs.python.org/issue13611 Stefan

[issue36346] Prepare for removing the legacy Unicode C API

Stefan Behnel added the comment: I had also looked through the unrelated changes, and while, yes, they are unrelated, they seemed to be correct and reasonable modernisations of the code base while touching it. They could be moved to a separate PR, but there is a relatively high risk

[issue36346] Prepare for removing the legacy Unicode C API

Stefan Behnel added the comment: I think this is a good preparation that makes it clear what code will eventually be removed, and allows testing without it. No idea how happy Windows users will be about all of this, but I consider it quite an overall improvement for the Unicode

[issue36346] Prepare for removing the legacy Unicode C API

Stefan Behnel added the comment: Thanks for implementing this, Serhiy. Since these C macros are public, should they be named PY_* ? -- ___ Python tracker <https://bugs.python.org/issue36

[issue36346] Prepare for removing the legacy Unicode C API

Change by Stefan Behnel : -- nosy: +scoder ___ Python tracker <https://bugs.python.org/issue36346> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34160] ElementTree not preserving attribute order

Stefan Behnel added the comment: Victor, as much as I appreciate backwards compatibility, I really don't think it's a big deal in this case. In fact, it might not even apply. My (somewhat educated) gut feeling is that most users simply won't care or won't even notice the change. Out

[issue34160] ElementTree not preserving attribute order

Stefan Behnel added the comment: :) The coolest thing about it is: it's not a hack at all. It's simply making use of the new feature in a suitable way. -- ___ Python tracker <https://bugs.python.org/issue34

[issue34160] ElementTree not preserving attribute order

Stefan Behnel added the comment: Something like this: def sort_attributes(root): for el in root.iter(): attrib = el.attrib if len(attrib) > 1: attribs = sorted(attrib.items()) attrib.clear() attrib.update(attr

[issue34160] ElementTree not preserving attribute order

Stefan Behnel added the comment: Ned, would it solve your problem to write a helper function that walks the tree and sorts the attrib dicts? That would also work in all existing CPython versions (because they already sort attributes anyway), for both ElementTree and lxml, and you wouldn't

[issue34160] ElementTree not preserving attribute order

Stefan Behnel added the comment: FWIW, I second Raymond's opposition against a new option. It's really not something that users should care about. Instead of us providing a new "sort or not" option, and people adding it (conditionally!) to their code to "fix" previous

[issue36233] xml ElementTree quotation marks of xml version string

Stefan Behnel added the comment: While I do understand the interest in a bit more visual consistency (and, lacking further input, I assume that this is the OP's "problem"), it really is at best a purely visual improvement with the potential to break code and/or tests out there.

[issue36227] Add default_namespace argument to xml.etree.ElementTree.tostring()

Stefan Behnel added the comment: lxml does not support the "default_namespace" option specifically (because its tree model preserves namespace prefixes), but it generally makes all (justifiable) serialisation options available to both tostring() and ET.write(). I think the same sh

[issue36227] Add default_namespace argument to xml.etree.ElementTree.tostring()

Stefan Behnel added the comment: The feature seems reasonable to me and the patch looks good. -- ___ Python tracker <https://bugs.python.org/issue36227> ___ ___

Re: [Python-ideas] PEP: Dict addition and subtraction

INADA Naoki schrieb am 05.03.19 um 08:03:> On Tue, Mar 5, 2019 at 12:02 AM Stefan Behnel wrote: >> INADA Naoki schrieb am 04.03.19 um 11:15: >>> Why statement is not enough? >> >> I'm not sure I understand why you're asking this, but a statement is >> &

Re: [Python-ideas] PEP: Dict addition and subtraction

INADA Naoki schrieb am 04.03.19 um 11:15: > Why statement is not enough? I'm not sure I understand why you're asking this, but a statement is "not enough" because it's a statement and not an expression. It does not replace the convenience of an expression. Stefan

[issue36144] Dictionary addition.

Stefan Behnel added the comment: > should we also implement +/+= for sets? The question is: what would that do? The same as '|=' ? That would be rather confusing, I think. "|" (meaning: "or") seems a very natural operation for sets, in the same way that "|&q

Re: [Python-ideas] PEP: Dict addition and subtraction

Jimmy Girardet schrieb am 04.03.19 um 10:12: > I'm not old on this list but every time there is a proposal, the answer > is "what are you trying to solve ?". > > Since > > |z ={**x,**y} and z.update(y) Exists, I can"t find the answer. I think the main intentions is to close a gap in the

Re: [Python-ideas] PEP: Dict addition and subtraction

James Lu schrieb am 04.03.19 um 03:28: > I propose that the + sign merge two python dictionaries such that if there > are conflicting keys, a KeyError is thrown. Please, no. That would be really annoying. If you need that feature, it can become a new method on dicts. Stefan

Re: [Python-ideas] Dict joining using + and +=

Rémi Lapeyre schrieb am 01.03.19 um 16:44: > Le 1 mars 2019 à 16:04:47, Stefan Behnel a écrit: >> I think the behaviour makes sense when you know how it's implemented (keys >> are stored separately from values). > > Is a Python user expected to know the implementation de

Re: [Python-ideas] Dict joining using + and +=

Eric V. Smith schrieb am 01.03.19 um 15:49: > I understand Inada to be saying that each value on the LHS (as shown above) > affects the result on the RHS. That's the case with addition of ints and > other types, but not so with the proposed dict addition. As he says, the > {a:1} doesn't affect the

Re: [Python-ideas] Dict joining using + and +=

Rémi Lapeyre schrieb am 01.03.19 um 15:50: > Le 1 mars 2019 à 15:41:52, Stefan Behnel a écrit: > >> Rémi Lapeyre schrieb am 01.03.19 um 15:06: >>> I’m having issues to understand the semantics of d1 + d2. >>> >>> I think mappings are more complicated

Re: [Python-ideas] Dict joining using + and +=

Rémi Lapeyre schrieb am 01.03.19 um 15:06: > I’m having issues to understand the semantics of d1 + d2. > > I think mappings are more complicated than sequences it some things > seems not obvious to me. > > What would be OrderedDict1 + OrderedDict2, in which positions would be > the resulting

Re: Using PyArg_ParseTuple to with optional fields.

Anthony Flury via Python-list schrieb am 28.02.19 um 10:18: > I am trying to write an extension module with a function (actually an > __init__ method, but I am not sure that matters) where the function can be > called as either : > >     my_func() > > or > >     my_func( a, b, c, d) - where

<    1   2   3   4   5   6   7   8   9   10   >