msg79183 - (view) |
Author: Jean-Paul Calderone (exarkun) *  |
Date: 2009-01-05 19:08 |
In order to create an element with an attribute and a child, this is necessary: e = Element("foo") e.setAttribute("bar", "baz") e.appendChild(quux) It would be preferable if Element.__init__ accepted two additional parameters to shorten this: e = Element("foo", attributes={"bar": "baz"}, children=[quux]) It may also be preferable to have a third new parameter, attributesNS, to parallel the Element.setAttributeNS method. This would accept a dict mapping namespaceURI and qualifiedName to an attribute value. |
|
|
msg108192 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2010-06-19 18:11 |
As you Jean-Paul Calderone seem to know what you're talking about could you provide a patch to get this issue going? If not I might even have a go myself, even if I do get shot down in flames. |
|
|
msg111724 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2010-07-27 20:19 |
I think this could be sneaked into 3.2 if needed, but is it more work than the benefits actually deliver in the real world? |
|
|
msg161577 - (view) |
Author: Alexander O (avono) |
Date: 2012-05-25 12:07 |
stupid question but why shouldn't this be possible ? class Element(_Element): def __init__(self,name,**kwargs): _Element.__init__(self,name) attributes = kwargs.get("attributes") children = kwargs.get("children") for key,value in attributes.iteritems(): self.setAttribute(key,value) for child in children: self.appendChild(child) |
|
|
msg162080 - (view) |
Author: Alexandre Zani (Alexandre.Zani) |
Date: 2012-06-01 17:11 |
I would tend to disagree with the use of **kwargs. It means the argument list would be implicit, not documented by the code and not checked at runtime. We could end up with anything in there. I'll try to propose a patch tonight that implements Jean-Paul's solution. |
|
|
msg162123 - (view) |
Author: Alexandre Zani (Alexandre.Zani) |
Date: 2012-06-02 05:00 |
Here is my patch for it. |
|
|
msg162341 - (view) |
Author: Alexander O (avono) |
Date: 2012-06-05 13:47 |
On Jun 2, 2012 7:00 AM, "Alexandre Zani" <report@bugs.python.org> wrote: > > Alexandre Zani <alexandre.zani@gmail.com> added the comment: > > Here is my patch for it. > > ---------- > keywords: +patch > Added file: http://bugs.python.org/file25796/easier_element_init.patch > > _______________________________________ > Python tracker <report@bugs.python.org> > <http://bugs.python.org/issue4849> > _______________________________________ > |
|
|
msg212986 - (view) |
Author: Jessica McKellar (jesstess) *  |
Date: 2014-03-09 21:23 |
Thanks for the patch, Alexandre.Zani! |
|
|
msg212987 - (view) |
Author: Jessica McKellar (jesstess) *  |
Date: 2014-03-09 21:27 |
Sorry, stray submit, one more time: Thanks for the patch, Alexandre.Zani! Your patch had some whitespace issues according to `make patchcheck` (see http://docs.python.org/devguide/patch.html#generation for details). I've uploaded a trivial update to your patch that passes patchcheck. The patch applies cleanly and test_minidom passes. This enhancement may need some documentation on the new constructor before getting merged, but let's get a design review going. => patch review |
|
|
msg409141 - (view) |
Author: mike mcleod (mikecmcleod) * |
Date: 2021-12-24 13:01 |
I would like to help with this issue. I'm new to this space hence I am not aware of what patch review means. |
|
|
msg409521 - (view) |
Author: Hugo van Kemenade (hugovk) *  |
Date: 2022-01-02 20:29 |
Hi Mike, "patch review" means: "A patch or pull request exists, but it needs review. Any triager or core developer may do the review." https://devguide.python.org/triaging/#stage So we were waiting for someone to review patches listed above under the "Files" section (eg. issue4849_2.patch). But seeing as they're from 2012/2014, and development has now moved to GitHub, a pull request needs to be opened on GitHub instead. So I reckon you're good to go ahead and create a PR. |
|
|