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
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. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "I saw `cout' being shifted "Hello world" times to the left and stopped right there." --Steve Gonedes
Paul Moore wrote:
On 6/9/06, Aahz <aahz@pythoncraft.com> 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. Georg
On Friday, June 09, 2006, at 03:34PM, Georg Brandl <g.brandl@gmx.net> wrote:
Paul Moore wrote:
On 6/9/06, Aahz <aahz@pythoncraft.com> 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
On Fri, Jun 09, 2006, Paul Moore wrote:
On 6/9/06, Aahz <aahz@pythoncraft.com> 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 (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/
"I saw `cout' being shifted "Hello world" times to the left and stopped right there." --Steve Gonedes
On 6/9/06, Aahz <aahz@pythoncraft.com> wrote:
On Fri, Jun 09, 2006, Paul Moore wrote:
On 6/9/06, Aahz <aahz@pythoncraft.com> 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
Note the magic word, "called": centurion:~/python/python/trunk > python2.4 Python 2.4.4c0 (#2, Jun 8 2006, 01:12:27) [GCC 4.1.2 20060604 (prerelease) (Debian 4.1.1-2)] on linux2 Type "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 > ./python Python 2.5a2 (trunk:46753, Jun 8 2006, 17:46:46) [GCC 4.1.2 20060604 (prerelease) (Debian 4.1.1-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
quit() centurion:~/python/python/trunk >
-- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
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#SECTION0001310000000000000000>. (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
On 6/8/06, Neal Norwitz <nnorwitz@gmail.com> 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/)
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>
I will be looking at the open AST issues today. Jeremy On 6/9/06, Neal Norwitz <nnorwitz@gmail.com> 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
Neal Norwitz wrote:
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
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. </F>
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>
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 | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
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>
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
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
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
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
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
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" <martin@v.loewis.de> 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/)
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
participants (15)
-
"Martin v. Löwis" -
A.M. Kuchling -
Aahz -
engelbert.gruber＠ssg.co.at -
Fred L. Drake, Jr. -
Fredrik Lundh -
Georg Brandl -
Guido van Rossum -
Jeremy Hylton -
Neal Norwitz -
Nick Coghlan -
Paul Moore -
Ronald Oussoren -
Simon Percivall -
Thomas Wouters