[Python-Dev] Doc suggestion for Elementtree (for 2.5? a bit late, I know...)

2006-08-28 Thread Paul Moore 
One little addition to the elementtree docs. In the overview section,
adding a paragraph explaining best practice for importing the module
might be useful.

Some suggested text, for the "overview" section:

"""
The ElementTree module comes in two forms - a pure-python version
(xml.etree.ElementTree) and a C-coded implementation
(xml.etree.cElementTree) which is faster. To import the faster code if
possible, but fall back to the Python implementation, you can use

try:
from xml.etree import cElementTree as ET
except ImportError:
from xml.etree import ElementTree as ET

ElementTree is also available as an external module for older Python
versions. For portability to these versions, this pattern can be
extended to

try:
from xml.etree import cElementTree as ET
except ImportError:
try:
from xml.etree import ElementTree as ET
except ImportError:
try:
import cElementTree as ET
except ImportError:
import ElementTree as ET

"""

I'd put a patch on SF, but guess what? It's down again :-(

Paul.

PS This actually begs the question - are there platforms where
xml.etree.cElementTree is not available? If not, is there a need for
both versions? If there are, the wording above should probably be
modified to reflect this.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Doc suggestion for Elementtree (for 2.5? a bit late, I know...)

2006-08-28 Thread Fredrik Lundh 
Paul Moore wrote:

> One little addition to the elementtree docs. In the overview section,
> adding a paragraph explaining best practice for importing the module
> might be useful.

good idea.

> PS This actually begs the question - are there platforms where
> xml.etree.cElementTree is not available?

not really; I usually recommend checking for

xml.etree.cElementTree
cElementTree
elementtree.ElementTree

in that order, if you just want to get the "best" implementation.

(there are some subtle differences between the C implementations
and the Python implementations, so people who do non-standard
stuff may want to use xml.etree.ElementTree, but I don't think that
has to be mentioned in the overview)

 



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] distutils patch

2006-08-28 Thread Russell E. Owen 
A colleague stumbled across distutils bug/misfeature that he found had 
been reported with an associated patch:


and I'm wondering if there's any plans to accept the patch or implement 
some other fix (such as raising an exception if one tries to use a blank 
package name). The current behavior is clearly unexpected and confusing. 
If there's something I can do to help get a fix of some kind into python 
2.5, I'm happy to do it.

Regards,

-- Russell

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] distutils patch

2006-08-28 Thread Martin v. Löwis 
Russell E. Owen schrieb:
> A colleague stumbled across distutils bug/misfeature that he found had 
> been reported with an associated patch:
>  d=5470&atid=305470>
> 
> and I'm wondering if there's any plans to accept the patch or implement 
> some other fix (such as raising an exception if one tries to use a blank 
> package name). The current behavior is clearly unexpected and confusing. 
> If there's something I can do to help get a fix of some kind into python 
> 2.5, I'm happy to do it.

As you can see from my comment, I think it really is a bug in the
application. Without reviewing it again, I think disallowing empty
package names might be the right thing; this can only be done in 2.6,
though.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Doc suggestion for Elementtree (for 2.5? a bit late, I know...)

2006-08-28 Thread Greg Ewing 
Paul Moore wrote:

> The ElementTree module comes in two forms - a pure-python version
> (xml.etree.ElementTree) and a C-coded implementation
> (xml.etree.cElementTree) which is faster.

If this is to be in the stdlib, is there any chance
of tidying up the convoluted, uninituitive and
non-pep8-compliant module naming structure?

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Doc suggestion for Elementtree (for 2.5? a bit late, I know...)

2006-08-28 Thread Steve Holden 
Greg Ewing wrote:
> Paul Moore wrote:
> 
> 
>>The ElementTree module comes in two forms - a pure-python version
>>(xml.etree.ElementTree) and a C-coded implementation
>>(xml.etree.cElementTree) which is faster.
> 
> 
> If this is to be in the stdlib, is there any chance
> of tidying up the convoluted, uninituitive and
> non-pep8-compliant module naming structure?
> 
I'm guessing the answer is "no" since the objection was only raised when 
the code had been incorporated into a release candidate. It was probably 
"no" from the beginning given that there was already substantial usage 
of the code before it was adopted for the stdlib.

Standards, apparently, are for *other* people :-)

It would be good if 3.0 was *much* more hard-nosed about naming 
conventions. How can we expect the community as a whole to take them 
seriously if we don't take them seriously ourselves?

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd  http://www.holdenweb.com
Skype: holdenweb   http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] draft for bug guidelines

2006-08-28 Thread Steve Holden 
Brett Cannon wrote:
> Made it the first step.  =)
> 
> -Brett
> 
> On 8/24/06, *Oleg Broytmann* <[EMAIL PROTECTED] 
> > wrote:
> 
> On Thu, Aug 24, 2006 at 12:21:06PM -0700, Brett Cannon wrote:
>  > Start a new bug
> 
>"Before starting a new bug please try to search if the bug has
> already
> been reported. It it has - do not start a new report, add your
> comments to
> the existing report."
> 
You probably want to include some advice about how. Isn't this rather an 
inappropriate time to be writing SF user notes, given that you are 
planning to provide us with an alternative to SF by the end of the year?

The last thing we need is a "how to submit a bug" article that sends 
people to the wrong repository ...

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd  http://www.holdenweb.com
Skype: holdenweb   http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com