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.

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.

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?

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)

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.

Here is my patch for it.

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>
> _______________________________________
>

Thanks for the patch, Alexandre.Zani!

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

I would like to help with this issue. I'm new to this space hence I am not aware of what patch review means.

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.