Re: [Python-Dev] 2.5 issues need resolving in a few days
On Sat, 10 Jun 2006, Fredrik Lundh wrote:
if all undocumented modules had as much documentation and articles as
ET, the world would be a lot better documented ;-)
I've posted a text version of the xml.etree.ElementTree PythonDoc here:
http://www.python.org/sf/1504046
hopefully, one of the anything-to-latex volunteers will pick this up
shortly; otherwise, I'll deal with that early next week.
i am new to anything-to-latex but gave it a try
elementtree.txt is the modified text version
1. add a classifier to function and class documentation
2. remove the Arguments:/Returns: definition lists, first because the
tool does not handle it in a useful way, second i couldnt find this
style in lib/*.tex and therefore dont know how it should be handled.
elementtree.text is the version generated from this version (rst2docpy)
cheers:Module: elementtree
:Summary: The xml.etree.ElementTree Module
:Module Type: standard
:Author: Fredrik Lundh [EMAIL PROTECTED]
:Version Added: 2.5
:Synopsis: This module provides implementations of the Element and ElementTree
types, plus support classes.
A C version of this API is available as xml.etree.cElementTree.
Overview
The Element type is a flexible container object, designed to store
hierarchical data structures in memory. The type can be described as a
cross between a list and a dictionary.
Each element has a number of properties associated with it:
* a tag. This is a string identifying what kind of data
this element represents (the element type, in other words).
* a number of attributes, stored in a Python dictionary.
* a text string.
* an optional tail string.
* a number of child elements, stored in a Python sequence
To create an element instance, use the Element or SubElement factory
functions.
The ElementTree class can be used to wrap an element
structure, and convert it from and to XML.
Functions
-
Comment(text=None) : funcdesc
Comment element factory. This factory function creates a special
element that will be serialized as an XML comment.
The comment string can be either an 8-bit ASCII string or a Unicode
string.
text: A string containing the comment string.
Returns: An element instance, representing a comment.
dump(elem) : funcdesc
Writes an element tree or element structure to sys.stdout. This
function should be used for debugging only.
The exact output format is implementation dependent. In this
version, it's written as an ordinary XML file.
elem: An element tree or an individual element.
Element(tag, attrib={}, **extra) : funcdesc
Element factory. This function returns an object implementing the
standard Element interface. The exact class or type of that object
is implementation dependent, but it will always be compatible with
the _ElementInterface class in this module.
The element name, attribute names, and attribute values can be
either 8-bit ASCII strings or Unicode strings.
tag: The element name.
attrib: An optional dictionary, containing element attributes.
extra: Additional attributes, given as keyword arguments.
Returns: An element instance.
fromstring(text) : funcdesc
Parses an XML document from a string constant. Same as XML.
source: A string containing XML data.
Returns: An Element instance.
iselement(element) : funcdesc
Checks if an object appears to be a valid element object.
element: element instance.
Returns: A true value if this is an element object.
iterparse(source, events=None) : funcdesc
Parses an XML document into an element tree incrementally, and reports
what's going on to the user.
source: A filename or file object containing XML data.
events: A list of events to report back. If omitted, only end
events are reported.
Returns: A (event, elem) iterator.
parse(source, parser=None) : funcdesc
Parses an XML document into an element tree.
source: A filename or file object containing XML data.
parser: An optional parser instance. If not given, the
standard XMLTreeBuilder parser is used.
Returns: An ElementTree instance
ProcessingInstruction(target, text=None) : funcdesc
PI element factory. This factory function creates a special element
that will be serialized as an XML processing instruction.
target: A string containing the PI target.
text: A string containing the PI contents, if any.
Returns: An element instance, representing a PI.
SubElement(parent, tag, attrib={}, **extra) : funcdesc
Subelement factory. This function creates an element instance, and
appends it to an existing element.
The element name, attribute names, and attribute values can be
either 8-bit ASCII strings or Unicode strings.
parent: The parent element.
tag: The subelement name.
attrib: An optional dictionary, containing element attributes.
Re: [Python-Dev] 2.5 issues need resolving in a few days
On Sat, 10 Jun 2006, Fredrik Lundh wrote:
if all undocumented modules had as much documentation and articles as
ET, the world would be a lot better documented ;-)
I've posted a text version of the xml.etree.ElementTree PythonDoc here:
http://www.python.org/sf/1504046
hopefully, one of the anything-to-latex volunteers will pick this up
shortly; otherwise, I'll deal with that early next week.
i am new to anything-to-latex but gave it a try
elementtree.txt is the modified text version
1. add a classifier to function and class documentation
2. remove the Arguments:/Returns: definition lists, first because the
tool does not handle it in a useful way, second i couldnt find this
style in lib/*.tex and therefore dont know how it should be handled.
elementtree.text is the version generated from this version (rst2docpy)
cheers:Module: elementtree
:Summary: The xml.etree.ElementTree Module
:Module Type: standard
:Author: Fredrik Lundh [EMAIL PROTECTED]
:Version Added: 2.5
:Synopsis: This module provides implementations of the Element and ElementTree
types, plus support classes.
A C version of this API is available as xml.etree.cElementTree.
Overview
The Element type is a flexible container object, designed to store
hierarchical data structures in memory. The type can be described as a
cross between a list and a dictionary.
Each element has a number of properties associated with it:
* a tag. This is a string identifying what kind of data
this element represents (the element type, in other words).
* a number of attributes, stored in a Python dictionary.
* a text string.
* an optional tail string.
* a number of child elements, stored in a Python sequence
To create an element instance, use the Element or SubElement factory
functions.
The ElementTree class can be used to wrap an element
structure, and convert it from and to XML.
Functions
-
Comment(text=None) : funcdesc
Comment element factory. This factory function creates a special
element that will be serialized as an XML comment.
The comment string can be either an 8-bit ASCII string or a Unicode
string.
text: A string containing the comment string.
Returns: An element instance, representing a comment.
dump(elem) : funcdesc
Writes an element tree or element structure to sys.stdout. This
function should be used for debugging only.
The exact output format is implementation dependent. In this
version, it's written as an ordinary XML file.
elem: An element tree or an individual element.
Element(tag, attrib={}, **extra) : funcdesc
Element factory. This function returns an object implementing the
standard Element interface. The exact class or type of that object
is implementation dependent, but it will always be compatible with
the _ElementInterface class in this module.
The element name, attribute names, and attribute values can be
either 8-bit ASCII strings or Unicode strings.
tag: The element name.
attrib: An optional dictionary, containing element attributes.
extra: Additional attributes, given as keyword arguments.
Returns: An element instance.
fromstring(text) : funcdesc
Parses an XML document from a string constant. Same as XML.
source: A string containing XML data.
Returns: An Element instance.
iselement(element) : funcdesc
Checks if an object appears to be a valid element object.
element: element instance.
Returns: A true value if this is an element object.
iterparse(source, events=None) : funcdesc
Parses an XML document into an element tree incrementally, and reports
what's going on to the user.
source: A filename or file object containing XML data.
events: A list of events to report back. If omitted, only end
events are reported.
Returns: A (event, elem) iterator.
parse(source, parser=None) : funcdesc
Parses an XML document into an element tree.
source: A filename or file object containing XML data.
parser: An optional parser instance. If not given, the
standard XMLTreeBuilder parser is used.
Returns: An ElementTree instance
ProcessingInstruction(target, text=None) : funcdesc
PI element factory. This factory function creates a special element
that will be serialized as an XML processing instruction.
target: A string containing the PI target.
text: A string containing the PI contents, if any.
Returns: An element instance, representing a PI.
SubElement(parent, tag, attrib={}, **extra) : funcdesc
Subelement factory. This function creates an element instance, and
appends it to an existing element.
The element name, attribute names, and attribute values can be
either 8-bit ASCII strings or Unicode strings.
parent: The parent element.
tag: The subelement name.
attrib: An optional dictionary, containing element
Re: [Python-Dev] 2.5 issues need resolving in a few days
PyXML appears pretty stable (in terms of release frequency -- I have no opinion on the code quality :-). Perhaps it could just be incorporated into the Python svn tree, if the various owners are willing to sign a contributor statement? --Guido On 6/11/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Neal Norwitz wrote: The most important outstanding issue is the xmlplus/xmlcore issue. It's not going to get fixed unless someone works on it. There's only a few days left before beta 1. Can someone please address this? From my point of view, I shall consider them resolved/irrelevant: I'm going to step down as a PyXML maintainer, so I don't have to worry anymore about how to maintain PyXML. If PyXML then gets unmaintained, the problem goes away, otherwise, the new maintainer will have to find a solution. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
Guido van Rossum wrote: PyXML appears pretty stable (in terms of release frequency -- I have no opinion on the code quality :-). Perhaps it could just be incorporated into the Python svn tree, if the various owners are willing to sign a contributor statement? That is, in itself, a medium-sized project. There are many components to PyXML, and finding all the authors might be a challenge already. Some code is outdated, and part of PyXML only to support old applications; that should not be moved into Python. Some code is still incomplete. I used to say it's work in progress, but for some of it, that isn't really true. Still, there are users of these pieces as well. The only parts that I personally would like to see in Python is some XPath implementation, and some XSLT implementation. Others might have other preferences, of course. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
Fred L. Drake, Jr. wrote: On Saturday 10 June 2006 12:34, Fredrik Lundh wrote: if all undocumented modules had as much documentation and articles as ET, the world would be a lot better documented ;-) I've posted a text version of the xml.etree.ElementTree PythonDoc here: Here's a question that we should answer before the beta: With the introduction of the xmlcore package in Python 2.5, should we document xml.etree or xmlcore.etree? If someone installs PyXML with Python 2.5, I don't think they're going to get xml.etree, which will be really confusing. We can be sure that xmlcore.etree will be there. I'd rather not propogate the pain caused xml package insanity any further. +1 for 'xmlcore.etree'. I don't use XML very much, and it was thoroughly confusing to find that published XML related code didn't work on my machine, even though the stdlib claimed to provide an 'xml' module (naturally, the published code needed the full version of PyXML, but I didn't know that at the time). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
Fred L. Drake, Jr. wrote: With the introduction of the xmlcore package in Python 2.5, should we document xml.etree or xmlcore.etree? If someone installs PyXML with Python 2.5, I don't think they're going to get xml.etree, which will be really confusing. We can be sure that xmlcore.etree will be there. I think it would be unfortunate if an external, mostly unmaintained package could claim absolute ownership of the xml package root. how about tweaking the xml loader to map xml.foo to _xmlplus.foo only if that subpackage really exists ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
On 11 jun 2006, at 12.09, Fredrik Lundh wrote: Fred L. Drake, Jr. wrote: With the introduction of the xmlcore package in Python 2.5, should we document xml.etree or xmlcore.etree? If someone installs PyXML with Python 2.5, I don't think they're going to get xml.etree, which will be really confusing. We can be sure that xmlcore.etree will be there. I think it would be unfortunate if an external, mostly unmaintained package could claim absolute ownership of the xml package root. how about tweaking the xml loader to map xml.foo to _xmlplus.foo only if that subpackage really exists ? I'm a bit confused by what the problem is. I though this was all handled like it should be now. import xml.etree xml.etree module 'xml.etree' from '.../lib/python2.5/xmlcore/etree/ __init__.pyc' import xml.sax xml.sax module 'xml.sax' from '.../lib/python2.5/site-packages/_xmlplus/ sax/__init__.pyc' It picks up modules from both places //Simon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
Simon Percivall wrote: how about tweaking the xml loader to map xml.foo to _xmlplus.foo only if that subpackage really exists ? I'm a bit confused by what the problem is. I though this was all handled like it should be now. that's how I thought things were done, but then I read Fred's post, and looked at the source code, and didn't see this line: _xmlplus.__path__.extend(xmlcore.__path__) or-maybe-someone's-been-using-the-time-machine-ly yrs /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
Neal Norwitz wrote: The most important outstanding issue is the xmlplus/xmlcore issue. It's not going to get fixed unless someone works on it. There's only a few days left before beta 1. Can someone please address this? From my point of view, I shall consider them resolved/irrelevant: I'm going to step down as a PyXML maintainer, so I don't have to worry anymore about how to maintain PyXML. If PyXML then gets unmaintained, the problem goes away, otherwise, the new maintainer will have to find a solution. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
On Saturday 10 June 2006 12:34, Fredrik Lundh wrote: if all undocumented modules had as much documentation and articles as ET, the world would be a lot better documented ;-) I've posted a text version of the xml.etree.ElementTree PythonDoc here: Here's a question that we should answer before the beta: With the introduction of the xmlcore package in Python 2.5, should we document xml.etree or xmlcore.etree? If someone installs PyXML with Python 2.5, I don't think they're going to get xml.etree, which will be really confusing. We can be sure that xmlcore.etree will be there. I'd rather not propogate the pain caused xml package insanity any further. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.5 issues need resolving in a few days
The most important outstanding issue is the xmlplus/xmlcore issue. It's not going to get fixed unless someone works on it. There's only a few days left before beta 1. Can someone please address this? If that means reverting changes to maintain compatibility, so be it. There is still the missing documentation for ctypes and element tree. I know there's been progress on ctypes. What are we going to do about ElementTree? Are we going to have another undocumented module in the core or should we pull ET out (that would also fix the xml issue)? Finally, there are the AST regressions. If there are patches that address any of these issues, respond with a link here. I'm guessing that all the possible features are not going to make it into 2.5. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
On 6/9/06, Aahz [EMAIL PROTECTED] wrote: There was also discussion of a change to the way quit works in interactive mode. I see no record of it, so I guess that's not going in, either. It's already in 2.5a2, if I'm thinking of the same thing you are... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
On Friday, June 09, 2006, at 03:34PM, Georg Brandl [EMAIL PROTECTED] wrote: Paul Moore wrote: On 6/9/06, Aahz [EMAIL PROTECTED] wrote: There was also discussion of a change to the way quit works in interactive mode. I see no record of it, so I guess that's not going in, either. It's already in 2.5a2, if I'm thinking of the same thing you are... Paul. It is, but it seems to disturb IDLE. That's no problem for me, but if someone is using IDLE, he should look into it. It doesn't disturb IDLE, but doesn't work in IDLE either. IDLE overrides the exit and quit builtins with different messages, hence IDLE users won't see the new behaviour. Ronald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
On 6/8/06, Neal Norwitz [EMAIL PROTECTED] wrote: The most important outstanding issue is the xmlplus/xmlcore issue. It's not going to get fixed unless someone works on it. There's only a few days left before beta 1. Can someone please address this? If that means reverting changes to maintain compatibility, so be it. Really? The old situation is really evil, and the new approach is at least marginally better by giving users a way to migrate to a new non-evil approach. What exactly is the backwards incompatibility you speak of? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
On Fri, Jun 09, 2006, Paul Moore wrote: On 6/9/06, Aahz [EMAIL PROTECTED] wrote: There was also discussion of a change to the way quit works in interactive mode. I see no record of it, so I guess that's not going in, either. It's already in 2.5a2, if I'm thinking of the same thing you are... Okay, I guess I mis-remembered what had been agreed to. Should this go into What's New? This also disagrees with Misc/NEWS: - Patch #1446372: quit and exit can now be called from the interactive interpreter to exit. Here are my tests: : python Python 2.4 (#1, Jan 17 2005, 14:59:14) [GCC 3.3.3 (NetBSD nb3 20040520)] on netbsd2 Type help, copyright, credits or license for more information. quit 'Use Ctrl-D (i.e. EOF) to exit.' ./python Python 2.5a2 (trunk:46583, May 31 2006, 20:56:06) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)] on linux2 Type help, copyright, credits or license for more information. quit Use quit() or Ctrl-D (i.e. EOF) to exit -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ I saw `cout' being shifted Hello world times to the left and stopped right there. --Steve Gonedes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
On 6/9/06, Aahz [EMAIL PROTECTED] wrote: On Fri, Jun 09, 2006, Paul Moore wrote: On 6/9/06, Aahz [EMAIL PROTECTED] wrote: There was also discussion of a change to the way quit works in interactive mode.I see no record of it, so I guess that's not going in, either. It's already in 2.5a2, if I'm thinking of the same thing you are...Okay, I guess I mis-remembered what had been agreed to.Should this go into What's New?This also disagrees with Misc/NEWS:- Patch #1446372: quit and exit can now be called from the interactiveinterpreter to exit.Here are my tests:: pythonPython 2.4 (#1, Jan 17 2005, 14:59:14) [GCC 3.3.3 (NetBSD nb3 20040520)] on netbsd2Type help, copyright, credits or license for more information. quit'Use Ctrl-D (i.e. EOF) to exit.' ./pythonPython 2.5a2 (trunk:46583, May 31 2006, 20:56:06)[GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)] on linux2Type help, copyright, credits or license for more information. quitUse quit() or Ctrl-D (i.e. EOF) to exitNote the magic word, called:centurion:~/python/python/trunk python2.4Python 2.4.4c0 (#2, Jun 8 2006, 01:12:27) [GCC 4.1.2 20060604 (prerelease) (Debian 4.1.1-2)] on linux2Type help, copyright, credits or license for more information. quit()Traceback (most recent call last): File stdin, line 1, in ?TypeError: 'str' object is not callable centurion:~/python/python/trunk ./pythonPython 2.5a2 (trunk:46753, Jun 8 2006, 17:46:46) [GCC 4.1.2 20060604 (prerelease) (Debian 4.1.1-2)] on linux2Type help, copyright, credits or license for more information. quit()centurion:~/python/python/trunk -- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
On Fri, Jun 09, 2006 at 07:28:47AM -0700, Aahz wrote:
Okay, I guess I mis-remembered what had been agreed to. Should this go
into What's New?
Already there:
http://docs.python.org/dev/whatsnew/other-lang.html#SECTION000131.
(Fred, is it possible to set the anchors used for *sub*sections?
\label{} sets the filename used for sections, which is great, but
subsection URLs are still annoyingly long.)
--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
On Friday 09 June 2006 10:28, Guido van Rossum wrote: Really? The old situation is really evil, and the new approach is at least marginally better by giving users a way to migrate to a new non-evil approach. What exactly is the backwards incompatibility you speak of? The incompatibility depends on your point of view for this one. I don't think there is any for client code; you get the old behavior for the xml package, and predictable behavior for the xmlcore package. Martin's objection is that the sources for the xmlcore package can no longer be shared with the PyXML project. I understand that he wants to reduce the cost of maintaining two trees for what's essentially the same code. I played with some ideas for making the tree more agnostic to where it really lives, but wasn't particularly successful. When I was working on that, I found that the PyXML unit tests weren't passing. I didn't have time to pursue that, though. On the whole, I'm unconvinced that there's value in continuing to worry about being able to copy the source tree between the two projects at this time. There's almost no effort going into PyXML any more, as far as I can tell. In that light, the maintenance cost seems irrelevant compared to not finally solving the fundamental problem of magic in the xml package import. I must consider the problem a nice-to-solve issue rather than a particularly important issue. All the benefit is for PyXML, and shouldn't really impact Python releases. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
I will be looking at the open AST issues today. Jeremy On 6/9/06, Neal Norwitz [EMAIL PROTECTED] wrote: The most important outstanding issue is the xmlplus/xmlcore issue. It's not going to get fixed unless someone works on it. There's only a few days left before beta 1. Can someone please address this? If that means reverting changes to maintain compatibility, so be it. There is still the missing documentation for ctypes and element tree. I know there's been progress on ctypes. What are we going to do about ElementTree? Are we going to have another undocumented module in the core or should we pull ET out (that would also fix the xml issue)? Finally, there are the AST regressions. If there are patches that address any of these issues, respond with a link here. I'm guessing that all the possible features are not going to make it into 2.5. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
